xml-dev - Re: Requirements for making DTD validation work with namespaces

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

Perhaps "contradicts" is not adequate. Perhaps "supersedes" is better.
While a processor which tracks both cat-1/2 validity and cat-5 validity
is conceivable, I'd be surprised if it were worth the effort. My sense
of the data model which would be effective to support those respective
validity criteria which concern symbol identity is that it would be
"difficult" to manage an efficient representation which supported
cat-1/2 and cat-5 categorizations simultaneously, and thus it would be
necessary to maintain distinct, duplicate models. In the sense that the
duplication entails time and space demands to which one would not likely
wish to accede, the categories "contradict" each other. Where I follow
my prejudices, the "cat-5 adequate" model is better for the cases which
I find useful, so I don't bother with the "cat-1/2 adequate" model. In
that sense cat-5 "supersedes".

Case in point: "naive DTD integration". Where two document types have
been designed without regard for namespaces, the respective DTDs may
well each contain declarations for elements with the same unprefixed
QName, for example
  <!ELEMENT element ... >
This would violate the "unique element type declaration" constraint and
imply a cat-2 status. Should the processor be cat-5, then the presence
of the following in the internal subset
  <!ATTLIST element xmlns CDATA #FIXED "namespace1">
  <!-- read first dtd -->
  <!ATTLIST element xmlns CDATA #FIXED "namespace2">
  <!-- read second DTD -->
should well entail the two distinct universal names {namespace1}element
and {namespace2}element. [Scoping rules, such as those required for such
a mechanism, are implied by the passage which describes the "prefix
declared" namespace constraint. The spec, unfortunately, never says what
they are.] Should a processor wish to model names such that it is
capable of this form of distinction between universal names - a form
which is necessary for useful cat-5 judgments, and, "at the same time"
also make cat-1/2 judgments, then, I suggest, it will need to duplicate
many aspects of its document model. 


"Winchel 'Todd' Vincent, III" wrote:
> 
> >
> > >The mechanism to which I alluded below neither ignores the problem nor
> > >does it entail parameter entities, and it conforms to three of the five
> > >constraints. Item 5 contradicts 1 and 2 and it doesn't make sense to
> > >implement both.
> >
> > I don't see how item 5 contradicts 1 or 2.
> >
> > It creates a new category of documents, distinct from "valid" and
> "invalid",
> > as defined in XML 1.0.
> 
> I don't see how item 5 contradicts 1 or 2 either.  The use of the word
> "SOME" might be changed.  So, for instance, this might be better:
> 
> >    5. SOME XML 1.0 documents that are Well-Formed, Invalid, and conform to
> > >the XML Namespaces REC, are considered to be "Namespace-Valid".
> 
> 5. Namespace-Valid documents are well-formed, conform to the XML Namespace
> REC, but would be invalid but for Namespace-validation.
> 
> That is a bit awkward too, but it is more precise than "some".
> 
> Otherwise,  these requirements are excellent.
> 
> >
> > How you define this category is the whole point - everyone seems to have
> > ideas about this.
> >
> > I will not budge from requirements 1 - 3.
> > 3 is where a lot of proposals fall down.

As I suggest as well.

> 
> When you say, "All namespace declarations work just as in XML Namespaces
> REC," does this mean, they all work as they would in non-validating and
> validating parsers, but they work differently in a Namespace-validating
> parser, because the behavior of such a parser must be different to validate
> a well-formed document against two or more DTDs?
> 
> I don't see how this will work (without changing XML 1.0 or Namespaces)
> without creating a new class of parser.  Of course, this changes parser
> behavior described in the specs, but it does not change the syntax mandated
> by the specs. [...]

It's not a new moninal class. It has been entailed in the specs all
along. Its implementation may have been rare, but that's another issue.

> 
> Todd