Namespaces hate validation!

[Murray Maloney]

At 05:15 AM 1/6/99 -0500, Ronald Bourret wrote:

>Murray Maloney wrote:
>
>> At 08:46 PM 1/5/99 -0500, Tim Bray wrote:
>>
>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.

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.

As I see it, Tim's algorithm is useful only if you are 
willing to write a new DTD for almost every document you get.
>
>(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.)

Right. Well, content="open" tries to merge well-formedness
with limited-validity. If that were an acceptable threshold
for validity, then XML should have incorporated it.
>
>> >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.

Sorry, I was being facetious.

Global attributes exist in "Namespaces in XML" but not in XML itself. 
Curious, no? My point is that "global attributes" as described in 
"Namespaces in XML" are a crock -- because there is no such thing as 
a global attribute "in XML".

>> >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

[...]

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

Please re-read what Tim said: "...declaring all the namespaces on 
the root element"

This assumes that all prefixes are unique. One cannot make such
an assumption. Hence, this aspect at least does not work.

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

I dispute "easy enough". If that is true, then please show evidence.
If someone would just send me the URL where I can find the listing 
of tools that automagically rewrites namespace-aware  XML DTDs for me, 
then I will reconsider my opinion. :-{

I assert that those of us who consider such a tool easy to create
are the ones who are least likely to actually write the tool.

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

Well, I just looked at XSchema again, and while it does include
some facilities for namespace-awareness, it is not clear to me
that it integrates "Namespaces in XML".

In a fact, I have to challenge your assertion that XSchema 
integrates with "Namespaces in XML". Quoting from XSchema (4.3.2):

	The following XSchema structures cannot be converted 
	to DTD structures because such structures do not exist:

	- More elements, AttDef and AttGroup elements that do not 
	  apply to a particular element, and Model and Enumeration 
	  elements nested directly beneath an XSchema element. 

	- All id attributes, all attributes of the XSchema element 
	  except for prefix, all ns and ElementNS attributes, and 
	  the Root attribute of the ElementDecl element. 

	- Nesting of schema information provided by nested XSchema 
	  elements.


------------
Please note that SOX also incorporates a namespace facility
which encompasses elements, attributes, notations, entities,
and processing instructions. Thus, it is not compatible with
the "Namespaces in XML" proposal.
>
>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.  

[...]

So, DCD does not integrate with "Namespaces in XML".

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

XSchema shows no such thing as section 4.3.2 makes clear.

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)