Re: [xml-dev] XML 2.0/Green or XMLE

["Pete Cordell" <petexmldev@codalogic.com>]

I too think a green computing initiative is worth looking at.  As I 
understand it, computing's carbon footprint is roughly the same as that as 
air travel (2%).  As an industry we tend not to be bothered about saving a 
few % of efficiency, but maybe it's time to realise that all those fractions 
of a percent could add up to real savings (which often make business sense, 
not just green sense).

I think James Clark's uXML covers most of the points you raise here so I'm 
hoping that will go forward.  I think we do still have to recognise that 
humans interact with XML, so I would keep the 5 main predefined entities. 
For the same reason I'd also keep allowing " and ' to delimit attribute 
values.  My experience is that that flexibility represents very little code 
to implement.

I wonder whether we'll see custom uXML hardware designed for super energy 
efficient message handling from which you can pull XML events from at the 
SAX level of granularity?

Interesting times!

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Rob Cameron" <robc@international-characters.com>
To: "xml-dev" <xml-dev@lists.xml.org>
Sent: Monday, December 13, 2010 3:20 PM
Subject: [xml-dev] XML 2.0/Green or XMLE


>
> XML 2.0/Green or XMLE
>
> Following on Pete Cordell's XML Lite idea, I suggest a slight
> varation with a focus on what might be the "killer app" to drive
> adoption: energy-efficiency for mobile and embedded applications.
> (I just now see James Clark's MicroXML, also on similar lines).
>
> From the energy-efficiency perspective, a primary goal is to
> reduce the number of processor cycles that need to be spent
> on parsing, including taking advantage of processor technology
> trends (SIMD and multicore parallelism, in particular).
>
> Given this perspective, it may be worth defining a variant
> of XML (say XMLE, where E stands for Embedded, or Energy-efficient,
> or Environmental) rather than a successor to XML 1.0.   Whereas
> an XML 2.0 may need to retain some features of XML 1.0 (e.g.,
> internal DTDs) for some important subclasses of nonembedded
> applications, XMLE might involve more radical simplification.
>
> Building on many of the ideas presented on the list and in
> Pete Cordell's XML Lite document, here is a list of possible
> simplifications, each of which will reduce cycles spent on
> parsing, as well as reducing complexity for building XMLE
> tools.
>
> Class A:  Restrictions that preserve XML 1.0 well-formedness
> (every XMLE document is also an XML 1.0 document).
>
> 1.  Eliminate DTDs - both internal and external
>       (also eliminate standalone declarations)
> 2.  Eliminate predefined entities
>       (use character references instead).
> 3.  Eliminate decimal character references in favor of
>      hexadecimal.  (Multiple representations add parsing cost
>      for no representational benefit; hexadecimal references
>      are best for simple and efficient conversion, including
>      parallel conversion.)
> 4.  Eliminate line break normalization costs, e.g. by making
>    CR illegal in XMLE (there are some other possibilities).
> 5.  Require UTF-8; eliminate encoding declarations.
> 6.  Require the use of double quotes and eliminate single
>    quotes for attribute values and the like.   There is a
>    parsing cost and no real representational gain in allowing
>    both forms.
> 7.  Eliminate CDATA sections.
> 8.  Eliminate comments in favor of processing instructions,
>    possibly with a predefined target.   (Or eliminate PIs
>    in favor of comments - either change has significant performance
>    benefits.   But processing instructions are used for
>    php and other scripting technologies.)
>
> Class B: Changes that will require a tool for conversion
>    from XMLE to XML 1.0.   Making any one of these changes
>    thus has a significant downside, because XMLE documents
>    will not be accepted by existing stacks.   However, the
>    performance benefits may be worthwhile.
>
> 1.  Eliminate element names in end tags; use the form "</>"
>    and possibly </n>, where n is nesting level.
>    (This change will considerably compress XML documents,
>     and may be enough to justify this whole class of changes.)
> 2.  Allow ]]> in text.
>
>
> Robert D. Cameron, Ph.D.
> Chief Technical Officer, International Characters, Inc.
> Professor of Computing Science, Simon Fraser University
>
> _______________________________________________________________________
>
> 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
>
>