|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Enlightenment via avoiding the T-word
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








