Lists Home |
Date Index |
- From: Ronald Bourret <firstname.lastname@example.org>
- To: "email@example.com" <firstname.lastname@example.org>
- Date: Wed, 6 Jan 1999 11:15:00 +0100
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.
<!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
> >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
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" />
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" />
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)