what did DTDs do to deserve such a bad rep[WD-xmlquery-use-cases-20010608 : 1.7.2 Document Type Definition (DTD)]

[james anderson <james.anderson@setf.de>]

I am working my way through the 20010608 xquery use cases - for the moment
still grappling with ambiguity in the grammar. I arrived at the NS use
case. The description of the respective document type definition runs as follows.

 "1.7.2 Document Type Definition (DTD)

  DTDs are not fully compatible with namespaces as they can not express the
  equality of nodes in the same namespace, but different namespace proxies.
  In a later version of this paper, an XML Schema should be added here."

I suggest that the first statement is neither, in general, true, nor do
the problems which might arise as a consequence of naive dtd
interpretation apply to the use case as formulated. Which would imply
that the delay suggested by the second statement is unwarranted.


As an aside, DTDs are, in themselves, compatible with namespaces. 

XML processors may well, as an unfortunate rule, ignore the namespace
information which is encoded in a dtd which leads them to interpret
homographs and synonyms naively and to misinterpret names.
This does not mean that a DTD cannot express the "equality of nodes ...".

A dtd which does express these relationships would, when taken together with
a document which depends its correct interpretation and used as a basis for
XML-1.0 validation, lead to the determination, that the document is invalid.
This also does not mean that a DTD cannot express the information.

It just means that the rules for XML-1.0 validation are not compatible with
universal names. That is no surprise. There is little reason to expect
to be able to infer anything useful about entities which include
universal names when one operates on them in a lexical domain.

For some inexplicable reasons, the standard response to this is to "wait
for schemas". Whatever the reasons may be, they should not impede a
complete formulation for this use case.

First, the NS case, at least at first examination, does not depend on
the correct interpretation of ambiguous qualified names. There may well
be an issue with modularity in content models, but this can be handled
by following simplified modularity guidelines.

Second, althought there is an instance of synonymy in the content of
Seller, it is not clear that it figures in the use case, and it could
well be handled with variability in the query and in the content models
for High_Bidder and Seller.

Third, in the only instance where synonymy might figure, Q7, the query
specifies a wild namespace.

In summary, the purported problem does not even affect the case.

In an effort to demonstrate this, I have posted, for examination, a
transcribed version of the data file (AuctionWatchList.xml[1]) together
with two DTDs (AuctionWatchList.dtd[2] and record.dtd[3]). I have also
posted the result of reserializing the parsed (validated) document.[4]
While this testing was done with a processor which operates directly on
universal names, the same ends should well be achievable with a
module-aware DTD.

...

[1] http://homepage.mac.com/james_anderson/XML/1-7-NS/AuctionWatchList.xml
[2] http://homepage.mac.com/james_anderson/XML/1-7-NS/AuctionWatchList.dtd
[3] http://homepage.mac.com/james_anderson/XML/1-7-NS/record.dtd
[4] http://homepage.mac.com/james_anderson/XML/1-7-NS/AuctionWatchListOut.xml