Altova Mailing List Archives


Re: [xml-dev] heritage (was Re: [xml-dev] SGML on the Web)

From: "Rick Jelliffe" <ricko@-------.---.-->
To: "'XML DEV'" <xml-dev@-----.---.--->
Date: 10/8/2002 2:07:00 PM
From: "Michael Kay" <michael.h.kay@n...>

> The fact that the model is retrofitted rather than being a
> normative part of XML means that questions like "are comments
> significant" have never been satisfactorily answered.

How can that question ever have a single answer?  

> And
> the confusion over marginally-significant stuff like CDATA sections,
> namespace prefixes, and inter-element whitespace continues to cause
> interoperability nightmares. If people had defined the model before
> defining the syntax we wouldn't be in this mess.

For marked sections, ISO 8879 says that marked sections

 - give the significance of a portion of data (i.e. should it be ignored,
is it temporary, should it be included) and/or
 - set a recognition mode for parsing. 

So a marked section was the SGML equivalent of cpp's #IFDEF.  
(XML does not have IGNORE marked sections in content, which
I suppose may be one reason for the LMNL stuff, though
presumably marked sections and LMNL would have different 
optimal grain sizes. )

If we ask about C "Is #IFDEF part of the C program's 'program model'" 
or does it disappear, then we probably give ourselves the an answer 
"well, its effects are, and probably a fancy IDE would maintain and
understand the #IFDEF structure, but the lion's share of tools shouldn't
care."  Which is exactly the same as the XML answer.  

Java has replaced #IFDEF but not completely satifactorily
(as anyone who has to resort to reflection to get a 1.4 program
to compile on 1.2 tools, or prepare stubs to get MRJ APIs
useful in non Mac tools can attest.)  Having a dumb macro
mechanism with a different syntax to fall back on as a last resort
is a great thing.   At the moment, XML has no standard way
of marking up the significance of parts, coping with variants
or change.  The nearest thing seems to be html:del!

Cheers
Rick Jelliffe

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.