• From: "Pete Cordell" <petexmldev@c...>
• To: "Elliotte Rusty Harold" <elharo@i...>,"XML Developers List" <xml-dev@l...>
• Date: Sat, 4 Dec 2010 13:59:43 -0000

I added the following comments on Elliotte's proposal (I'm not sure where 
the best place for such a discussion is):

_Neurotic and psychotic documents_

I'm not sure that limiting namespace declarations to the root element is 
that important, but my experience is that it would help if all namespace 
prefixes were declared before any other attributes in a start tag.  This 
reduces the amount you have to look ahead in event driven code.

_White space preservation_

I think the default should be to preserve white space, even in attributes. 
The application can decide to discard it with methods like 
getTextCollapse(), getTextReplace() and getTextPreserve().  By removing 
white space you're modifying the data and I don't see that what is 
effectively a transit layer should have the authority to do that.

_More entities_

I disagree with including more built-in entities.  Getting the characters 
that you want in a document should be an editor issue and not an XML issue.

In the area of entities, the choice of '&' as the escape character seems 
very unfortunate.  It's too late to change this, but I think the character 
sequences '&', '>', '<', '&apos', and '"' should cause the 
replacement they currently do, but any other sequence following an '&' 
character should have no special meaning.  Thus, if you type '& then', your 
parser returns '& then' rather than an error.

_Data Structures and Types_

I like the idea of xml:type, but I think it's only required for complex 
types when mirroring the functionality of polymorphism.  It's not required 
for simple types.  If an application doesn't know what an 'X' is, then 
knowing that it is an 'int' is not really going to help it.

_Comments_

I would allow -- (two dashes) to appear in comments.  There's no benefit to 
not allowing -- and it reduces the surprises that a novice user might 
encounter.  (In fact 'A minimum of surprises' should be an XML 2.0 axiom!)

I think the XML 2.0 spec should have a 'Compatibility' section in it that 
says if you want your XML 2.0 document to be valid XML 1.0, then take note 
of the following ... .  One of the things it would mention is comments.

HTH,

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: "Elliotte Rusty Harold" <elharo@i...>
To: "XML Developers List" <xml-dev@l...>
Sent: Saturday, December 04, 2010 12:18 PM
Subject:  Towards XML 2.0



First for the record, I’m speaking only for myself, not my employer,
the W3C, Apple, Google, Microsoft, WWWAC, the DNRC, the NFL, etc.

I'd like to throw a hat in the ring. I think it's time to do XML 2.0,
and I think we should do it. Of course, that depends on what XML 2.0
is.

XML 1.1 failed. Why? It broke compatibility with XML 1.0 while not
offering anyone any features they needed or wanted. It was not
synchronous with tools, parsers, or other specs like XML Schemas. This
may not have been crippling had anyone actually wanted XML 1.1, but no
one did. There was simply no reason for anyone to upgrade. By contrast
XML did succeed in replacing SGML because:

   1. It was compatible. It was a subset of SGML, not a superset or an
incompatible intersection (aside from a couple of very minor technical
points no one cared about in practice)
   2. It offered new features people actually wanted.
   3. It was simpler than what it replaced, not more complex.
   4. It put more information into the documents themselves. Documents
were more self-contained. You no longer needed to parse a DTD before
parsing a document.

To do better we have to fix these flaws. That is, XML 2.0 should be to
XML 1.0 as XML 1.0 was to SGML, not like XML 1.1 was to XML 1.0. That
is, it should be:

   1. Compatible with XML 1.0 without upgrading tools.
   2. Add new features lots of folks want (but without breaking
backwards compatibility).
   3. Simpler and more efficient.
   4. Put more information into the documents themselves. You no
longer need to parse a schema to find the types of elements.

These goals feel contradictory, but I plan to show they’re not; and
map out a path forward. You'll find the technical details at
http://cafe.elharo.com/xml/xml-2-0/ but those are just a straw man,
and I expect they will change in detail as we move forward. If the
basic goals sound right to you--backwards compatibility, new features,
simpler and more self-contained documents--then let me know. I'd like
to put together a small group of experienced and interested folks to
actually bang out a draft specification. If nothing else, it will give
us something to talk about at Balisage next year. :-)

-- 
Elliotte Rusty Harold
elharo@i...

_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

• Follow-Ups:
  • Re: Towards XML 2.0
    • From: Elliotte Rusty Harold <elharo@i...>

• References:
  • Towards XML 2.0
    • From: Elliotte Rusty Harold <elharo@i...>