[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: malfunctioning, evil adult as XML

• To: 'Rick Jelliffe' <ricko@a...>, xml-dev@l...
• Subject: RE: malfunctioning, evil adult as XML
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Mon, 3 Feb 2003 10:13:39 -0600

From: Rick Jelliffe [mailto:ricko@a...]

>But XML is broken for that anyway: because standalone="yes"
>is voluntary and probably ignored by recipients anyway, you cannot
>guarantee that if you need to take advantage of XML's expressive
>power (e.g. use entities, attribute defaulting, external subsets, etc) 
>the receiver will end up with the same infoset.  

I agree.  This puts XML back to where SGML was during the 
ESIS/Unicorn discussions.

>The result is this cart-before-the-horseism that vomits itself up
>on XML-DEV every few microseconds: "I want to get rid of 
>the parts of XML I don't use".  Rather than "Lets fix the parts
>that are broken", which is constructive and congenial. 

I mostly agree.  Some assert the need to "bless" subsets 
they are already applying by formal specification (soap)
The danger asserted is that "subsets growing in the wild" will 
lead to broken interoperability.  The counter-argument is 
that attempting to get all of the requirements for different 
groups into one subset or even a few is as likely to cause 
interoperability problems.  The third position is, Works 
As Designed.  Don't touch.  I think the first position is
suspect or at least unsupported.  The second position 
depends on how processors are required to recognize 
instances that the sender assumes rely on the subset 
features at the receiving node.  The third position isn't 
hard to support, status quo, because it translates to 
use the specification as designed and ensure the receivers 
do the appropriate filtering.

>W3C should
> 1)  Deprecate Well-Formedness for public specs, documents and
>data interchange (it is a niche thing only suitable for editors); 

After five years of the XML core telling the public that well-formedness 
is the sine qua non of XML, that will be a hard sell however 
rational it may be.  They don't usually admit they are wrong.

>and
> 2) Give a formal name for a headless XML, in which a DOCTYPE
> declaration is an error (and make it a little simpler: don't check
>  naming rules or normalization) SOAP can use this.

Agreed.

> 3) Give a formal name for an unvalidated, guaranteed-infoset XML:
> all parameter entities fetched, defaults applied, entities defined,
> IDs typed, but content models not checked.  XHMTL can use this.

Agreed but as you point out, the trick is the guaranteed infoset.

>Solutions like "get rid of attributes/entities and everything will be well"
>look like armchair speculation to me: the trick is not to come up with
>a tidy idea, but to come up with a practical one that moves us forward.

I agree with that wholeheartedly, but I am old enough to remember systemts 
that tried that approach to SGML.  They became dust buckets.

len

• Prev by Date: Re: XML Editors supporting change tracking (redliningetc.)
• Next by Date: ANN: Examplotron 0.7
• Previous by thread: RE: malfunctioning, evil adult as XML
• Next by thread: Re: The patron saints of XML WAS: Are There URIs in Heaven?
• Index(es):
  • Date
  • Thread