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