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

Re: Implementations not specifications are the problem was Re:

• To: Jonathan Borden <jborden@m...>, xml-dev@l..., Sean McGrath <sean.mcgrath@p...>
• Subject: Re: Implementations not specifications are the problem was Re: IDs considered harmful
• From: James Clark <jjc@j...>
• Date: Wed, 14 Nov 2001 08:14:33 +0700
• In-reply-to: <024c01c16c4d$4dc48190$0a2e249b@n...>
• References: <024c01c16c4d$4dc48190$0a2e249b@n...>

>> "(iii) It doesn't work with streaming output. This is in my view the most
>> important technical problem"
>>
>
> Err, so wouldn't it be easier to fix the streaming output systems (I
> believe Xalan already implements the SAX DeclHandler interface on its
> default output handler) than to:
>
> 1) Create an entirely new specification
> 2) Update every XML parser and XPath and DOM implementation
> 3) Deploy the new implementions
>
> The problem is in _implementations_ not _specifications_.
>
> Perhaps I am missing something?

No amount of fixing implementations will solve the problem.  The problem is 
exacerbated by the mismatch between the infoset and the serialized form (as 
Mike Kay points out): ID-ness is a property of attribute information items 
in the infoset but is serialized in the DTD. But even if this was fixed, it 
wouldn't solve the fundamental problem.  Imagine trying to implement 
something like XInclude whilst preserving the ID-ness of attributes.  If 
IDs have to be declared up front in the internal subset, it is impossible 
to implement in a 1-pass streaming way.  With xml:idatts it would be 
possible (modulo problems with duplicate IDs). XSLT implementations have an 
equivalent problem.

Note that the issue of streaming output is the main reason why namespace 
declarations were allowed to nest rather that being all required up front 
on the document element. See

http://www.w3.org/DesignIssues/Extensible.html#Local

> James:
>
> On the other hand I _do_ think there is value in 'moving beyond' DTDs to
> XML syntax schemas. Since you are working with RELAXNG, rather than
> propose _xml:atts_ which is a partial solution to the problem, will you
> include the _xml:atts_ proposal as a part of RELAXNG in some fashion?

The RELAX NG DTD Compatibility spec

  http://www.oasis-open.org/committees/relax-ng/compatibility.html

provides a DTD-compatible ID facility.  However, I'm not a big fan of IDs. 
I strongly dislike the kind of redundant markup that ID/IDREF based linking 
often forces:

  A <termdef id="dt-well-formed">well-formed</termdef> document is...

  A <termref ref="dt-well-formed">well-formed</termref> document must...

I prefer something along the lines of XSD identity constraints, except (i) 
it should be specifiable and useable independently of the other parts of 
the schema and (ii) it needs to support keyrefs to hierarchichal systems of 
keys. I hope at some point there will be a companion spec to RELAX NG that 
provides this.

James

• Follow-Ups:
  • xml:dtatts for DTDless XML was Re: Implementations not specifications are the problem
    • From: "Jonathan Borden" <jborden@m...>

• References:
  • Implementations not specifications are the problem was Re: IDs considered harmful
    • From: "Jonathan Borden" <jborden@m...>

• Prev by Date: Re: DOM or SAX: Sense and Sensibility
• Next by Date: Re: annotations outside validation
• Previous by thread: Re: Implementations not specifications are the problem was Re: IDs considered harmful
• Next by thread: xml:dtatts for DTDless XML was Re: Implementations not specifications are the problem
• Index(es):
  • Date
  • Thread