Lists Home |
Date Index |
- From: Murray Maloney <firstname.lastname@example.org>
- To: "email@example.com" <firstname.lastname@example.org>
- Date: Wed, 6 Jan 1999 17:09:13 -0500
At 01:51 PM 1/6/99 -0500, Tim Bray wrote:
>At 12:39 PM 1/6/99 -0500, Murray Maloney wrote:
>>Easy enough to write a DTD that matches an instance. Just inspect
>>the instance and generate a DTD that captures its models.
>>The trick is to be able to write a DTD that encompasses
>>a class of documents that might be validated by it.
>Exactly. Of course, in historical practice, we kind of did this
>with well-known external entities such as %ISOLat1; and CALS tables
>and so on - this had two big problems: first, there was no way to
>ensure avoidance of name collisions, and second, there was no
>generally agreed upon way of resolving the PUBLIC identifiers.
>Namespaces would allow creation of a solution that would avoid both
Two big problems.
Problem 2. Well, I don't understand your point about the PUBLIC ids
because XML relies on SYSTEM ids and not on PUBLIC ids. Besides,
the SGML Open catalog specification handles PUBLIC ids.
Problem 1. Name collision.
We agree that this can be ameliorated by using prefixes.
This introduces new big problems. Prefixes do not exist in
flat "Namespace in XML" documents. That is, the namespace of
an element or attribute may be the current default namespace,
and any element can establish the default. Furthermore, the
binding of a namespace prefix to URI can be locally scoped.
Thus validation depends on the existence of a namespace-aware
processor that can rewrite an XML document as an equivalent
document with all namespaces declared on the root element
and with no use of default namespaces or local scoping
And, that processor is undefined and unimplemented.
"Namespaces in XML" does not clearly define the relationship
between itself and XML 1.0 validity. In technical specs,
where one measure of friendliness toward a given topic is
the sufficiency of coverage, I have to say that the absence
of a clear definition of this relationship is tantamount to hate.
>... Once you've written your compound DTD, the idea is that
>the algorithm uses it to validate documents that may or may
>not conform to it. Once the hard part - writing the compound
>DTD - is done, the algorithm does the rest, hands-off.
This I have to see. And when I see it, I may come to believe.
But in the meantime, my skepticism is at perigee.
Oh, by the way, what do you do about any entities you encounter?
I mean, when I combine an HTML DTD with a graveyard DTD,
how do I avoid name collision between general text entities?
agrave, egrave, igrave, ograve, ugrave
Now I assume that you will tell me that there is a *simple*
algorithm for transforming the DTD and/or the instance to
deal with name collisions.
>DCD was certainly 100% explicitly namespace-aware, and had
>facilities for including foreign-namespace elements in
>content models and attribute lists. You may disagree with
>aspects of that design, but a flat statement of "I do not see
>how to integrate namespaces with schemas" is not useful.
While I do disagree with certain aspects of the design of DCD,
it is also true that SOX was informed by many of the other
schema languages (DCD, XML-Data, XSchema, EXPRESS, XML DTDs).
So, if I give the impression that I completely dislike DCD,
please accept my apology. What I actually said was:
>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.
That statement was useful if only to encourage you and others
to "show me the error of my ways." But so far I am not seeing
thing much different. I do acknowledge that it is theoretically
(and maybe even practically) possible to create processors
that prepare a namespace-aware XML document for validation.
But I have serious doubts about when such a processor will
I believe strongly in the "no harm, no foul" principle.
That is, so long as a design characteristic or feature
causes no harm to any other part of the system, then
there is no reason to cry "Foul!". I find that the proposed
"Namespaces in XML" is harmful to validation because it establishes
a dependency on an un-defined, un-developed and non-standard class
of XML processor. And it is harmful to XML schema languages
by denying the use of name collision facilities for entities,
notations and processing instructions.
>>So, DCD does not integrate with "Namespaces in XML".
>DCD has one missing piece: the syntax for prefix/URI mapping. That
>was deliberate, because that ball was still in play when DCD was
>being written. This is not a credible technical objection. -Tim
Huh? Even XML DTDs can use prefixes without any help at all.
Any schema language that does not have prefix/URI mapping,
would seem to be incomplete with respect to "Namespaces in XML".
The point is, there is not a single schema language in play
that fully addresses its relationship to "Namespaces in XML".
There are all kinds of questions that remain either unanswered
Murray Maloney, Esq. Phone: (905) 509-9120
Muzmo Communication Inc. Fax: (905) 509-8637
671 Cowan Circle Email: email@example.com
Pickering, Ontario Email: firstname.lastname@example.org
Canada, L1W 3K6
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)