Lists Home |
Date Index |
- From: Wayne Steele <firstname.lastname@example.org>
- To: email@example.com, firstname.lastname@example.org, email@example.com
- Date: Thu, 17 Aug 2000 12:42:15 -0700 (PDT)
IMHO, that solution (like just about every other one I've heard) is lacking.
I believe Microsoft tried something like that, with unpleasant and
incompatible results (Hint: try to declare an element with a colon in the
name, and no attributes, using MSXML 1.0).
WRT the earlier proposal by Paul Abrahams, let me draw your attention to the
following line from the XML Namespaces REC:
"No entity names, PI targets, or notation names contain any colons."
Everyone seems to have their own 'pet' schemes for making DTD validation
work with Namespaces.
To help further useful discussion of this, I propose the following:
Requirements for making DTD validation work with namespaces
I submit that any "special" processor behavior needs to be 100% compatible
with XML 1.0 and the XML Namespaces Rec:
1. All XML 1.0 Valid documents are still Valid;
2. All XML 1.0 Invalid documents are still Invalid;
3. All namespace declarations work just as in the XML Namespaces REC
(whether document is Valid or not)
A frequent proposal is creation of a new definition of "Namespace-Valid"
I also submit that, for this to work:
4. ALL XML 1.0 documents that are Valid and conform to the XML Namespaces
REC, are considered to be "Namespace-Valid";
5. SOME XML 1.0 documents that are Well-Formed, Invalid, and conform to
the XML Namespaces REC, are considered to be "Namespace-Valid".
I, for one, am not interested in any scheme for integrating DTDs and
Namespaces unless in adheres to all five requirements, above.
Sadly, the leading candidates seem to be:
1. Ignore the whole problem, and hope it goes away
2. Nested Parameter Entities, as used in the DTD for XML Schemas
>From: james anderson <firstname.lastname@example.org>
>If one were expect a processor to implement this mechanism, then one
>could just as well expect a processor to implement the mechanism which
>is already implied by the namespace spec. Namely, to observe attribute
>default bindings for namespace attributes when reading the dtd. If
>specified in the internal subset for the root element of a dtd fragment
>which is described externally, the encoding is not significantly more
>complex then the implicit qualification proposed here. It also requires
>just implementing things which are already described...
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com