Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Namespaces, schemas, Simon's filters.
 Tim, Uh, once again the parallel to the original namespace discussion is so revealing. As I recall, the same arguments were made about the linking from labels to namespaces - we could have stuck "namespace-pointer attributes" on every element designating what namespace it should go in. However, providing a 1-1 map from labels to namespaces was considered crucial, so now the labels themselves have been expanded to include the namespace. Do you think that was an error, and we should have adapted architectural forms? > -----Original Message----- > From: Tim Bray [mailto:tbray@t...] > Sent: Wednesday, August 29, 2001 11:53 AM > To: xml-dev@l... > Subject: RE: Namespaces, schemas, Simon's filters. > > > At 11:12 AM 29/08/01 -0700, Fuchs, Matthew wrote: > >One doesn't really need any new syntax. If we consider > complexTypes as > >introducing a new namespace (which we're perfectly free to > do - the NS rec > >doesn't say anything about how you create or name a > namespace, nor much > >about what a namespace is) then xsi:type is an attribute > that says "the > >default namespace within this element is the namespace created by the > >complexType with this name". That's it. > > Suppose I believe that it's crucially important to be able to map 1-1 > from labels to schema definitions (I don't, although Rick & Matt have > argued convincingly that it's good practice). Suppose I believe that > the way to accomplish this mapping is via the labels themselves (I > don't; I think decorating the instance with definition-pointer > attributes - from a different namespace, natch - is the way to go). > > If I believed those things, I'd be violently against tying namespace > creation to any particular schema language. That's not at all what I'm saying. Right now an XSDL schema "creates" a namespace with the targetNamespace attribute on the <schema> element (one can argue over "create", but it certainly is an assertion that the namespace exists) and all top-level elements declared in the schema are in it. Likewise, one can consider the creation of a complexType as likewise creating a namespace (or asserting the existence of a namespace) whose name is the concatenation of the enclosing namespace and the local name of the complexType (exact syntax open to discussion) and all elements declared immediately within it are in that namespace. This allows the schema designer to use XSDL syntax to assert the existence of some set of namespaces, and place his elements within them. > Matt is correct that the > NS rec says nothing about how you "create" a namespace, it just tells > you how to put elements and attributes in them. If what is > required is > a new way to put markup in namespaces, we'd need a generalized > interface for doing this that an XSDL processor or any other software > has access to. I also think that it's pretty important that > in general, > applications of different classes, upon reading a document, all agree > what namespaces pieces of markup are in. At the moment, the only > way I can see to accomplish this is by putting the namespace syntax > right there in the instance. -Tim > I agree. The truth is, if people do as I've suggested, we don't actually need _any_ new mechanism, although some new mechanism would be convenient. If we choose to treat complexTypes as namespaces, and in your schema you've declared local elements as being unqualified (not in a namespace) which means 1) they're unprefixed in the instance and 2) they're not in the scope of a default namespace declaration, then all you're doing is putting previously unqualified elements in a previously non-existent namespace. You can immediately update all your instances by adding default namespace attributes to the appropriate elements. If you've already put your local elements into the schema namespace, then adapting is much more difficult. Likewise, I suspect that updating applications is much easier in the former scenario than the latter. So there's no _need_ for new mechanism. However, it has been argued that a serious lacuna in the original NS rec is the lack of an attribute to specify a namespace that applies only to the _content_ of the current element, not the element itself. Let's call it xmlcont for the moment. Having such a thing would be very convenient, both for validating and non-validating applications. For example, if I'm inserting in one element content from another, with xmlcont I don't need to worry about prefix collisions, eg: Source: <a:foo xmlns:a="foo"> <a:e1/> <a:e2/> </a:foo> Target: <a:baz/> where a is defined somewhere above. Result: <a:foo xmlcont:a="foo"> <a:e1/> <a:e2/> </a:foo> Here I don't need to worry about prefixes and namespaces in the target document, as this a prefix only applies to the content I've moved over. So one could argue for the general relevance of such a thing without any discussion of XSDL, and one could ask what the original editors were smoking that they didn't put this feature in (but I won't do that because it hadn't occurred to me at the time anyway). But suppose we go a little farther with considering complexTypes as namespaces and realize that, since they have a content model, they're really both - a namespace with a content model. Then we could say a validating processor, when it sees a reference to a namespace with a content model, validates against that content model as well as putting things in the right namespace, and a non-validating processor, just puts things in the right namespace. Then we get rid of xsi:type because xmlcont does the same job but isn't as tied to XSDL. This is just one solution among others I've considered. It's probably the most friendly to the whole breadth of XML, but there are other. However, getting back to the root of this whole discussion, it requires keeping local elements unqualified for the nonce. 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
|
|||||||||
