RE: [xml-dev] Evolution of a markup language: replace recurring patterns

["Toby Considine" <Toby.Considine@gmail.com>]

Ahh, for the days of SVG as an XML island, with a second null XML island
with a few common schema touch points allowing one of many different data
domains to be delivered and change the roll-over / reporting attributes of
the graphics on the fly: energy management, space management, revenue per
square foot, information-sensitive  behaviors and styles. Perhaps subsidiary
null XML islands that when populated would drive business graphics as
data-aware roll-overs AJAX populate the secondary islands, and those islands
drive another SVG island of chart objects. Good times.

Then Adobe bought Flash, and killed SVG and those days would never come back
and SVG was dead. Only now SVG is climbing back from the ashes in HTML5, and
perhaps there will be use for XML islands again...


"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc
TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  
Email: Toby.Considine@gmail.com
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com


-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: Thursday, December 23, 2010 5:06 AM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Evolution of a markup language: replace recurring
patterns that are imperatively implemented with declarative solutions

Perhaps I should elaborate: with XML Data Islands (you don't hear much about
them these days) the XML was held in the HTML of the web page but you had to
use javascript to get at it and do things with it. Originally this tended to
mean using an ActiveX XML parser like MSXML in the web page and nowadays you
can probably rely on the browser's DOM to get at elements and attributes
with the Javascript. All this gets a bit messy (especially if ActiveX XML
parsers go through constant
updates) but maybe libraries like jQuery can help smotth out user experience
for a web developer.
XForms was supposed to improve the user experience still more, I think, but
I'm not sure it did. It should be possible to replace the Javascript and
'XML data island'
with an XForm and its 'model'
but I did find myself that I still needed some javascript even with an XForm
to anything my customer wanted and it meant instead of ActiveX you still
needed addins subject to the same constant updates and downloads. This was
perhaps evidence of browsers not supporting XML very well, and the
impression I got back then was it was semi-intentional (perhaps something to
do with big vendors protecting IP and business models???). Not that I'd want
to make any allegations but there would have been some very cool things
which should have been possible but they might have flown in the face of
what vendors wanted for the Web (and server sales, etc).

----
Stephen D Green



On 23 December 2010 09:46, Stephen Green <stephengreenubl@gmail.com> wrote:
>>
>> How has XML evolved? Can you cite examples of where usage patterns have
been observed and then equivalent declarative solutions have been provided?
>>
>
> I don't think you can say XML itself has evolved since, by design, 
> there has only been one version in a decade. However, I think a 
> classic XML-related example of the progress from Javascript to 
> declarative markup has been the evolution from XML Data Islands to 
> XForms.
>
> Regards
>
> ----
> Stephen D Green
>
>
>
> On 22 December 2010 14:50, Costello, Roger L. <costello@mitre.org> wrote:
>> Hi Folks,
>>
>> In this book [1] the author says that the members of the HTML5 working
group have identified recurring JavaScript patterns and then created
corresponding markup:
>>
>>   When JavaScript was introduced into web browsers, it
>>   was immediately seized upon for two tasks: Image rollovers
>>   and Form enhancements. When CSS came along with its
>>   :hover pseudo-class, web designers no longer needed to reach
>>   for JavaScript just to achieve a simple rollover effect.
>>
>>   This is a recurring trend. If a pattern is popular enough, it
>>   will almost certainly evolve from requiring a scripted solution
>>   to something more declarative.
>>
>>   ...
>>
>>   Following the same migratory pattern from scripted to declarative
>>   solutions, the [HTML5] specification introduces many new form
>>   enhancements.
>>
>>   ...
>>
>>   HTML5--it's paving a cowpath ...
>>
>>
>> Another way of saying this is: HTML5 has migrated imperative code to
declarative markup.
>>
>> This is exciting.
>>
>>
>> The book gives this example of migrating imperative code to declarative
markup:
>>
>>    Here's a common DOM Scripting pattern, often used for
>>    search forms:
>>
>>    1. When a form field has no value, insert some placeholder text into
it.
>>
>>    2. When the user focuses on that field, remove the placeholder text.
>>
>>    3. If the user leaves the field and the field still has no value, 
>> reinstate the
>>       placeholder text.
>>
>>    In an HTML5 document, you can simply use the placeholder attribute:
>>
>>    <input id="hobbies" name="hobbies" type="text" placeholder="Owl 
>> stretching">
>>
>>
>> The HTML language is evolving by diligently observing usage patterns and
then creating equivalent markup. Thus, there is a slow but steady
progression away from the need for imperative code to declarative solutions.
>>
>> Cool.
>>
>> How has XML evolved? Can you cite examples of where usage patterns have
been observed and then equivalent declarative solutions have been provided?
>>
>> /Roger
>>
>> [1] "HTML5 For Web Designers" by Jeremy Keith, p. 40-43.
>>
>> _____________________________________________________________________
>> __
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS to 
>> support XML implementation and development. To minimize spam in the 
>> archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org List archive: 
>> http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support
XML implementation and development. To minimize spam in the archives, you
must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org List archive:
http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php