Namespaces hate validation!

[Murray Maloney]

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 
>those problems.

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 
of prefixes. 

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 
be standardized.

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
or untried.

Regards,

Murray






Murray Maloney, Esq.          Phone: (905) 509-9120
Muzmo Communication Inc.      Fax:   (905) 509-8637
671 Cowan Circle              Email: murray at muzmo.com
Pickering, Ontario 		Email: murray at yuri.org
Canada, L1W 3K6    		

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