OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Namespaces hate validation!

[ Lists Home | Date Index | Thread Index ]
  • From: Tim Bray <tbray@textuality.com>
  • To: Murray Maloney <murray@muzmo.com>, "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
  • Date: Wed, 06 Jan 1999 10:51:48 -0800

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.

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

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

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

No, because it's a new idea, and XML 1.0 was trying to crystallize
practice that had been shown to work.  Now we're trying to deal
with the new problems of compound documents.

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

The algorithm does *not* depend on the concept of global attributes.
The namespace draft introduces the concept, in a non-normative appendix,
simply as a device to aid in explaining the mapping of element types 
and attribute names to URIs.  

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

I'm missing your point.  Yes, XML lacks global attributes.  Why does
this make the use of the term, as an explanatory device in a 
non-normative appendix, a crock?

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

Obviously my explanation wasn't simple enough.  Suppose your instance
contains all sorts of namespace defaulting.  Suppose it also has
a namespace URI "A" mapped to two different prefixes in different
parts of the document, and suppose further it has a namespace URI "B"
mapped, in a different part of the document, to one of the same
prefixes that is used elsewhere for "A".  All these cause validation
problems.  The algorithm goes through the document, builds a table,
for every element & attribute, of its namespace (if any applies), makes
one unique prefix for each URI that is used anywhere, inserts 
declarations for all those prefixes on the root element, than for
each element and attribute that's in a namespace, puts the 
appropriate prefix on it.  No more defaulting, the same namespace/prefix
mappings used everywhere, everything explicit.  Now you can validate.

Sorry for not connecting the dots.  Murray, this does work.

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

Yes, you can, after you've rewritten them.

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

Yep, while it's not conceptually hard, it's kinda practically hard
right now because, as John Cowan et al point out, the existing
XML processors tend not to expose the DTD structures enough to 
provide the info that you need (even though it's there in the
document).

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

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.

>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

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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS