[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Enlightenment via avoiding the T-word
Yes, we seem to be getting closer. When we were trying to get the formal description (XSFD) [1] started, there was simply no way the T-word could bear all the overloading it got, so we ended up calling our things "sorts", as per the logic community rather than T#&$s. By the way, Tim, did you reread the definitions of local and global in XSDL, so we're on the same page as to what they are? While I know that XSFD is not for everyone, an examination of the discussion of normalized names near the beginning might be worthwhile. [1] http://www.w3.org/TR/xmlschema-formal/ Many more comments below.... > -----Original Message----- > From: Tim Bray [mailto:tbray@t...] > Sent: Monday, August 27, 2001 5:22 PM > To: xml-dev@l... > Subject: 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. Ulabels don't appear in the (source) doc. They are synthesized at one level or other of mapping. But that's a quibble. > 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> > _Very_ close! My what a good student! ;-) However, 1) XSDL does not require the existence of a single schema document, or even of any schema document. The schema is actually the set of components describing the constructs of the schema, which doesn't necessarily ever exist as a document. 2) The paths should be "canonical" in that we should be able to compare two paths and determine they indicate the same thing, without actually needing to check the document. So, what I've actually been advocating instead are the normalized names (now generally referred to as NUNs [normalized universal names]), which follow the logical structure of the Schema, rather than the syntax. Naturally they represent a path, but a path in the logical tree. XSDL currently has no means to support these. > >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. > Sorry. In the DTD world and the Schema world w/o local elements, for each valid element there is one and only one definition to which it corresponds. Once it's ulabeled, the ulabel is like a pointer - I can use it to locate any additional information I need. And in addition, even if I don't validate, the ulabels tell me what they should have been, so you can process my valid document according to the labels I give even if you don't also validate. (That, of course, is the source of Murata Makoto's objection to attribute defaults, etc.) If I keep local elements out of a namespace (for now), I still have this one-to-one map for everything that has a ulabel, and if something doesn't have a ulabel, at least I know it's an exception as soon as I see it and handle it accordingly. If I put local element in the schema namespace, I lose the one-to-one map for _everything_, so I always need to check context. What do I gain? Now me, I want a ulabeling mechanism for XSDL that does the same thing, including for local elements. My objection to just using the path expressions (or my NUNs) is that they require validation to appear, so it's hard for you to process my document unless you validate. I want a ulabeling mechanism that allows me to tell you, as with namespaces, what the unique ulabels are. You can munge then all you want after that, as Simon wants to, but at least you know what I meant. Suppose we do build the right mechanism for XSDL. What do we do with all the existing schemas? If we've gone and shoved all the local elements into the schema namespace, updating to a better mechanism will be very difficult. However, if we don't, we may be able to upgrade existing instances by "reinterpeting" with upgraded semantics. > >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! > Remember, this is only in the context of XSDL and how XSDL users assign labels. And, of course, the label is just the NUN of the element from the schema, so if you use schema, it would be the label _you_ created. If we consider XSDL complexT%^$s as creating namespaces, then they're namespace _you_ created using the facilities of XSDL. > > 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? > To start, people might actually try working with XSDL local types before voting. I realize that's not necessarily the American Way, but it might help. Arguments I have in favor include: 1) Otherwise there is no way to create a standalone document valid against a schema with local names - i.e., it would extend well-formedness to handle XSDL 2) From my experience, it will significantly simplify building tools that operate on schemata, such as class generators, schema repositories, editors, etc. While most readers may never build such things, they'll probably want to use some of them at some point, so there's no point in their going out of the way to make those tools harder to build and use. > > 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 Knee jerk reactionary ;-) It's not true that any namespace is better than no namespace. The right namespace is better than no namespace. Matthew
|
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
|