- From: Bullard, Claude L (Len) <clbullar@ingr.com>
- Date: Tue, 7 Jan 2003 15:49:21 -0600
- To: "'Chris Lilley'" <chris@w3.org>, www-tag@w3.org
That should be "require DTD or Schema validation of any instance requesting it". Why do it if you don't have to? You will have to and often but that is ok. A self-describing document is in for a pound if in for a penny. 1. Existing mechanism works. Extending system attributes endlessly on the root is poor. It is getting crowded in there with no end in sight. 2. Hinders composability. Not really. Hinders tools that are only well-formed aware. 3. Leaves well-formed documents in a backwater of their own making. Why not? Nothing breaks. Well-formedness has limits with regards to support of interoperable systems. This issue proves it by example. 4. Retrogressive step. Actually, putting more and more semantically loaded, system information into the root is retrogressive. Separating that into a well-defined, well-understood, and implemented piece that even if surface ugly, works, is good computer science. This is solving a problem of our own making. len From: Chris Lilley [mailto:chris@w3.org] 1) Require DTD validation of all instances. A fully validating XML processor will, almost as a side effect, result in all attributes of type ID being so noted in the Infoset. Advantages: - existing mechanism (DTDs) Disadvantages: - existing mechanism is poor, - not namespace aware, - can't declare a content model of 'any' that really means 'any', - can't use with mixed namespace documents easily - hinders composability - needlessly conflates validation with decoration - leaves well formed documents in a backwater - retrogressive step
Received on Tuesday, 7 January 2003 16:50:23 UTC