RE: Enlightenment via avoiding the T-word

[Tim Bray <tbray@textuality.com>]

At 03:34 PM 27/08/01 -0700, Fuchs, Matthew wrote:

Hey, I think Matt and I are actually communicating now!  See what
happens when you banish the T-word?

At this point, a review of 
 http://www.enm.bris.ac.uk/teaching/enbwp/emat107slides15.pdf
may be helpful to those who've forgotten about "bijective"
and "injective" and so on.  A bijective mapping between sets A 
and B is one-to-one and onto, i.e. you can pair the elements 
off and none them are in more than one pair, and every element 
of both is in a pair.  An injective mapping is the same, only 
you don't have to use all the elements of B.

>XSDL, however, is supposed to be a validation mechanism that supports
>Namespaces, as DTDs don't.  However, just as DTDs provide a mapping between
>labels and definitions, one would hope that XSDL would provide a bijection
>between ulabels and definitions - at least for elements.  Of course, this
>wouldn't exhaust the semantics that could be applied to structures, but at
>least within the context of working with XSDL, and for the benefit of people
>trying to use XSDL for work, it is highly desireable.  In other words, once
>a document has been validated, every element should have a ulabel, and from
>the ulabel alone you should be able establish which definition applies to
>that element within the context of XSDL validation.

Now here I *think* we have the heart of the disagreement.  Matt's core
point is that in schemas, unlike DTDs, the label or the ulabel as it 
appears in the doc doesn't of itself give you the definition.  Question: 
why is this a problem?  Over to Matt:

>  It just means that if people go through the (currently
>not insignificant) effort to use XSDL, that's one of important pieces of
>information XSDL should give them.  And, ta da!, it doesn't do that.  There
>is no injective mapping from ulabels to definitions.  A ulabel maps to a set
>of definitions, and if you want to know which is the "true" definition, you
>need to either reparse the surrounding element(s) or hope there's a PSVI
>available (not insignificant overhead for many processors) so you can do
>pointer comparisons, or whatnot.  

So the problem isn't that you can't find the appropriate schema
definition, it's that doing so can be expensive (I agree).  Since 
nobody is arguing that it's a bad idea to have context-sensitive 
content models, the problem is ensuring that you only have to look 
up the context - the computationally expensive part - once.  Here's 
a strawman "Plan B".  Suppose that as as a result of XSDL validation,
you attached to each element in the input document an XPath 
expression that points you to the applicable rule in the schema 
document.  <pedantry>It's not an injection on the element labels, 
it's an injection on the XPath expressions.</pedantry>

>However, if local elements (as described
>in XSDL) are not given ulabels (are unqualified), then you still get an
>injective mapping, and the hope of fixing things later (by retrofitting in
>the least disruptive way).

Huh?  An injective mapping on the combination of the label and 
its parent (or some ancestor) ulabel, right?  But (pardon me being
dense) I just don't see that the problem is made either worse or
better by whether or not the local elements are in a namespace.
Boy, this is making me feel stupid, my only consolation is the
feeling that others are equally puzzled.  Do it in words of
one syllable, Matt, and we'll eventually get it.

>An appropriate ulabeling mechanism for XSDL would provide an injective
>mapping for its own purposes. 

Would the XPath trick qualify?  Because there are a *lot* of 
philosophical problems with actually changing the element labels 
to accomplish this objective.  Keepa yo hands offa my labels, geekboy!

>   The lack of an injective
>mapping is, in my opinion, a major issue.  

It doesn't bother me at all... maybe a virtual show of hands
around here would be useful at this point?  Do most people care?

>  And in the meantime, if someone tells you, as an XSDL user, to just
>put all your elements in the schema namespace, just say no.

Put them all in *some* namespace, I say.  And don't rely on a
schema processor to do it for you. -T