OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Evolution of a markup language: replace recurringpatterns that are imperatively implemented with declarative solutions


A couple of notes - XML syntax has not evolved much at all from its inception. On the other hand, its core processing tools - validators, transformers and query mechanisms, have evolved dramatically. XSLT2 is unarguably a better product than XSLT1, but wouldn't have happened without a lot of rethinking about the underlying data model. Ditto XQuery. With the introduction of formal mechanisms for extension in both XSLT and XQuery, that pace of evolution is also accelerating, as it becomes possible to see what constructs are considered to be "basic" and which are framework extensions. XQuery 1.1 is now capable of managing extended mathematics functions, and XSLT2.1/3.0 has integrated streaming, which dramatically raises the stakes.

Indeed, I'd content that the XML world in 2010 is significantly richer in terms of functionality than it was in 2002.

As to HTML - there have been advocates for moving to a more declarative model in HTML for a long time now, but because the browser space had dwindled to Internet Explorer 6 and Opera in 2002, the pressure for change was non-existent. The JavaScript changes that came about occurred because Mozilla needed a way to both establish itself and re-energize the development base, and consequently were much more open to changing things - and to make JavaScript the means of implementing these changes, a philosophy that was largely pragmatic, as that was the one avenue of extension that was available to third party developers.

The evolution of declarative components in HTML5 has been done largely by fiat, and has been led primarily by Mozilla and, by 2009, by Google with Chrome. Those changes are welcome - I'm actually quite excited by the contenteditable attribute, for instance, <video> and <audio> treat other media in a manner that is now consistent with <img> (or its alias <image>, which is likely to be standardized in its stead), inline SVG should make for some cool apps and svg in the <image> tag is a definite place. The reality, however, is that standardization upon these tags brought sufficiently significant benefit that there really was very little rationale for not having them given declaratively.

I believe that the next evolutionary wave in browsers will be due to the formal acknowledgement of XBL2 as the preferred mechanism for performing bindings to content. Right now, jquery has become the "de facto" king of the hill with regard to ARIA/AJAX libraries, but these still involve involving scripting within the declarative markup. XBL2 shifts you to a much more fully declarative model, with the behaviors bound to specific tags. In HTML, this will likely create an overlay for the @class or @role attributes, in XHTML this will see a more formal introduction of elements with specific behaviors and semantics as well as presentation.

Similarly, I think that on the XML side, XQuery is likely going to be the dominant technology for determining the future evolution of the language + tech. It's more accessible than XSLT2 for many programmers, it works well in the XML database arena (which I see as an indispensible part of the evolution of this technology) and it can be used more effectively to tie into other systems (such as email, calls to relational databases and so forth) than XSLT can. If you can combine the two technologies (as is increasingly the case) you can get some amazing synergies as well, with XQuery handling the interfaces side and XSLT driving complex presentation, while XQuery also shapes the underlying data to be transformed.

XML Architect
Lockheed / US National Archives ERA Project

On Wed, Dec 22, 2010 at 9:50 AM, 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


  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.


How has XML evolved? Can you cite examples of where usage patterns have been observed and then equivalent declarative solutions have been provided?


[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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS