xml-dev - Common XML (was Re: Document Feature Requirements)

[Rick JELLIFFE <ricko@geotempo.com>]

Steven Rowe wrote:
 
> Is it not ironic that Common XML, an attempt to increase interoperability,
> excludes PIs, which are likely to be the mechanism which will be proposed
> to express document feature requirements, another attempt to increase
> interoperability.

I think the name "Common XML" doesn't capture where the Common XML
conventions are most appropriate. Some name like "Exchange XML" or
"Round-trippable XML"
would be more appropriate. 

I welcome Common XML. We need to keep a profile to let people know which
features have been implemented well or are appropriate at any time. As I
wrote
on xml.com  

 "I am happy for dialects ... (for) giving a well-thought-out way of 
 using or analyzing or implementing XML, but I think we lose out if it
is 
 promoted as an alternative syntax outside XML. " 

The sections on elements, attributes and namespaces seem like good
advice.

Some of the other sections don't seem to have good enough arguments to
be utterly convincing yet, however. In particular, the conclusions often
don't
seem to flow from the argument.

Does anyone else detect a running fallacy throughout some of the other
sections that goes "if you want to use an apple as an orange you cannot,
therefore you
should use only oranges and we don't need to provide apples"?  

For example, comments should not be used becuase it is impossible to
guarantee roundtripping or to transport data in them.  PIs are
"ambiguous"
"because they are not part of the document's character data" and "many
simple applications ignore or discard them".  CDATA section tags don't 
have semantic meaning. 

However, it is the nature of a comment that it is not data -- it is 
an annotation for the benefit of human readers on the state of the text
of a document.  Similarly, it is the nature of a processing instruction
that if the receiving system does not understand a PI with a particular
target (or with any particular target) the PI can be ignored-- a PI is
directed at particular applications which understand it, it is perhaps
essentially point-to-point.  And as for CDATA sections, a good reason
for deprecating them is that they can make XML-unaware text processing
break;
but I don't know if there are any XML processors that treat them wrongly
(except for IE5 display, I suppose, but that has been because certainly
at first IE5 did not redelimit the data before interpreting it as HTML
for
display: a bug in my book.)

I would say there is a further idea that needs to be addressed more
also:
an editing application is fundamentally different from a transformation
application.  If an editing application cannot round-trip, that is
a bug. If a transformation application cannot round-trip, that is the 
developer's choice (or the application domain's charactistic). 

Common XML is based on a model where the user of the data is not in the
position to choose tools that can handle that data. I think this is
not so likely for inhouse workflows of data, which is why "Exchange XML"
might be a better name.

'Guaranteed interoperability' and 'simplicity of implementation'
are sometimes at odds. A notable example is that of character encoding.
If your system is not native Unicode (or has a transcoding library such
as IBM's ICU for C++ available) then mandating UTF-8 is equivalent of
ruling out Chinese, Japanese and Korean data. In such a case,
interoperability 
equates to unuseability.  "Common XML" is, for us here, "Impossible XML"
as it stands, for many applications.

All that being said, it is good to see this first version of Common XML.
If we accept that we should be conservative in what we send and generous
in what we accept, then I hope that Common XML will stimulate developers
to check  "Am I stripping comments and PIs needlessly?" and so on.


Rick Jelliffe

[1] http://www.xml.com/pub/1999/12/sml/goldilocks.html

P.S. I tried to send these comments before to SML-DEV to comment on the
draft,
but the website swallowed my email with an error.

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************