xml-dev - RE: Namespaces hate validation!

[Ronald Bourret <rbourret@ito.tu-darmstadt.de>]

Murray Maloney wrote:

> At 08:46 PM 1/5/99 -0500, Tim Bray wrote:
>
> >1. You have a DTD that contains elements from different namespaces
> >   and you know what the URIs are for those namespaces.
>
> Everything that follows this point is predicated on the
> assumption that one can have such a DTD, but later Tim
> makes it clear that it is not currently feasible to design
> such a DTD. As Tim says, "we're nowhere near knowing the answer."

I don't think Tim is saying that at all.  Such a DTD is trivial to write. 
 For example:

<!ELEMENT fff:foo (bbb:bar)>
<!ELEMENT bbb:bar (#PCDATA)>

Furthermore, it would not be difficult to design an editor that allowed 
people to combine DTDs.  Such an editor would simply redefine elements as 
the user specified, writing the new element definitions to a new DTD and 
reusing the existing definitions.  The only thing in Tim's algorithm that 
is currently unspecified is how to tell the preprocessor what the 
prefix-to-URL associations used by the DTD are.

I think what Tim is saying is that it is non-trivial to automagically 
combine DTDs or in some sense to say that a given document validates 
against two or more different DTDs.  As XML currently stands, this seems to 
be possible only through the liberal use of ANY in content models, which is 
a less-than-optimal solution.

(I assume that the Contents=Open/Closed property in DCD is intended to 
address this further.  When an element is declared as having open contents, 
it can contain child elements that are not declared in its content model. 
 In other words, it allows schema designers to explicitly state where the 
content model can be altered/expanded.  This is the same as ANY except 
#PCDATA is not allowed unless it was in the original content model.  A 
further refinement would be to say that Contents=Open means that elements 
not declared in the current schema can occur as children.  This would meet 
the needs of schema merging without allowing people to "violate" the cur  
rent schema.)

> >5. You preprocess the DTD, rewriting all the element & attribute
> >   declarations with the appropriate prefixes
>
> Using special care to take into account the non-XML notion
> of "global attributes".

I don't understand this comment.  Global attributes don't currently exist 
in XML, so how can a DTD even contain them?  This comment makes sense only 
if you are using a schema language that supports global attributes, which 
doesn't apply in the case the algorithm addresses.

> >6. You preprocess the instance, making all namespace prefixes
> >   explicit (no defaulting), declaring all the namespaces on the root
> >   element, and using the same set of prefixes you used in the DTD
>
> Of course, this will not work for instances that redeclare
> a namespace prefix with a different URI for the purposes
> of local scoping of namespaces. In that case, you have to
> declare namespaces on elements as you go. And, since you
> would have to inspect the entire document to determine
> whether local scoping of namespaces has been applied,
> you simply cannot count on Tim's algorithm for the general
> case.

If you are stating that the algorithm doesn't work, it does: Prefixes are 
mapped first to URIs, then to unique prefixes.  Therefore, it doesn't 
matter if a prefix is reused in an instance -- at any given point in time, 
it maps to a unique URI, and thus to a unique prefix.

If you are stating that the algorithm doesn't work because you have to 
inspect the entire document first, that's a circular argument.  The 
algorithm clearly states that the document must be preprocessed, so you 
can't use that as an argument against it working.  (Note that such 
preprocessing is necessary to use the algorithm with current parsers.  This 
prefix substitution could be done at parse time by a specialized parser.)

> > Well, tedious enough to make it unlikely that anyone will use
> > validation on documents that utilize namespaces. It is hard.
> > It is too hard. And for that reason, among others, Veo has
> > vociferously opposed "Namespaces in XML".

This might be true, although it is easy enough to write a tool that did the 
preprocessing necessary for this to work with the current batch of parsers. 
 In the long run, these questions disappear anyway, as the current schema 
proposals can declare which namespace a given element or attribute belongs 
to, thus solving the problem of no namespace declarations in the DTD.

> As a co-author of one of the schema submissions, I have to say
> that I do not see how to integrate "Namespaces in XML" -- as
> it is currently proposed -- with an XML Schema language. Perhaps
> someone will show me the error of my ways in the fullness of time,
> but I am skeptical.

XSchema already does this.

DCD almost does this, but is silent on how it associates namespace prefixes 
used in attribute values (such as the name of an element being declared) 
with URIs.  The obvious solution to this -- to use namespace attributes -- 
is less than optimal.  For example, the following would work:

   <DCD xmlns:DCD="URI for DCD" xmlns:MyURL="URI for my namespace">
      <DCD:ElementDef Type="MyURL:MyType" />
   </DCD>

but isn't very user friendly.  It would be better to allow the user to 
avoid prefixes altogether:

   <ElementDef Type="MyType" />

Unfortunately, this isn't possible using namespace attributes, as it would 
require the user to declare the default namespace twice:

   <DCD xmlns="URI for DCD" xmlns="URI for my namespace">
      <ElementDef Type="MyType" />
   </DCD>

In any case, it is certainly possible to integrate the current namespace 
proposal with a schema language, as XSchema shows.

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)