[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespacePr
This has been a fascinating thread. As one of those who'd argued most vociferously for the current default mechanism in XML Schema, I'm going to try to briefly explain what's happening. Also, having been such a vociferous proponent of one side of this issue, I'll start by saying this was one of the most, if not the most, contentious issue(s) in the development of XML Schema. As a committee, we then chose the technically brilliant strategy of giving both sides what they wanted. As we can see, this remarkably improved XML Schema because, in retrospect, both sides were out to lunch. But more on that later. Right now, I just want to explain the rational behind the default behavior, which Aaron seems to realize (but I'll elaborate). First, XML Schema allows one to mix and match any number of schemas in a single instance. Each one of those schemas may have associated with it a namespace. One of those schemas is permitted to be unqualified. I'll say, right off the bat, that I think this is a _really_bad_thing_to_do_. Now, if you don't have any unqualified schemata in a document, then the default behavior of elementFormDefault gives the following invariants: 1) all top-level elements are always qualified 2) all locally declared elements are always unqualified From which one can derive the following hard and fast rule about locally scoped elements: 3) All unqualified elements are locally declared in the type of the immediately enclosing element (modulo inheritance) and therefore cannot be confused with any other unqualified element with the same local name declared in some other type. This should be enough to provide Simon with exactly the information he wants. We are using the qualified/unqualified distinction so that "Namespaces in XML provides a means of pinning down element and attribute identifiers to avoid potential conflicts". And this even without access to the schema. If on the other hand, one flips the behavior of elementFormDefault, then all locally declared elements show up as qualified in the schema of definition, but then one cannot distinguish among the various different elements in that schema which may have the same local name. Eg., suppose I have a schema in the "confused" namespace with global elements foo, bar, and baz, and foo has locally declared bar and baz elements, and bar has locally declared foo and baz, etc. Then if I have an instance: <c:foo xmlns:c="confused"> <c:bar> <c:baz> <c:foo/> </c:baz> </c:bar> <c:foo> then there are 3 declarations of c:bar in the "confused" schema, if elementFormDefault is qualified, which might apply - one actually needs the schema to be sure. However if elementFormDefault is unqualified, then c:bar can only be the global bar and one can tell that the c:bar above is the global one and in: <c:foo xmlns:c="confused"> <bar> <c:baz> <foo/> </c:baz> </bar> <c:foo> the bar and the inner foo _must_ be local, while the baz and outer foo must be global. On the downside, however, this approach works very badly with default namespaces, so if you're planning to always validate but like writing instances by hand (in which case flipping the default means you can use default namespaces), or if you need to use a schema with no namespace, this has problems. Which comes to why the solution arrived at by the W3C Schema WG is problematic - the real issue is how the _instance_ author wants to use qualification to convey information about his document. The _schema_ author cannot know what elements will appear in the instance, or which schemas will be mixed. Therefore the appropriate solution would be to get rid of elementFormDefault and provide appropriate mechanisms in the _instance_ to specify how this should work for the particular instance under consideration. Matthew > -----Original Message----- > From: Aaron Skonnard [mailto:aarons@d...] > Sent: Tuesday, July 31, 2001 9:21 PM > To: Xml-Dev > Subject: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for > NamespaceProcessing) > > > <snip/> > > [Simon] > > Namespaces in XML provides a means of pinning down element and > attribute > > identifiers to avoid potential conflicts. By blessing the use of > > unqualified names within namespace-qualified contexts, W3C > XML Schema > > makes precise identification of those identifiers a much > more complex > > task. > > On the contrary, consider the following XML schema definition > and sample > instance document: > > <!-- schema definition --> > <s:schema xmlns:s="http://www.w3.org/2001/XMLSchema" > xmlns:tns="http://example.org/foo" > targetNamespace="http://example.org/foo" > elementFormDefault="qualified"> > <s:element name="bar" type="s:string"/> > <s:complexType name="fooType"> > <s:sequence> > <s:element name="bar" type="s:string"/> > </s:sequence> > </s:complexType> > <s:element name="foo" type="tns:fooType"/> > </s:schema> > > <!-- instance --> > <f:foo xmlns:f="http://example.org/foo"> > <f:bar/> <--| > </f:foo> | > | > | > Even when everything is qualified, you still can't figure out > which bar > element this is just by looking at the QName and ignoring > context (is it > the global or local qualified bar element?). > > And since everyone's already used to dealing with attributes based on > context [1], I don't see why local elements complicates > things further. > As an example, consider the version attribute in XSLT. When used on a > literal result element, it must be qualified. But when used on the > xsl:transform element, it must be unqualified, depending completely on > context. > > The only thing that matters is that both sides know when local scoping > is in use - either via schema definitions or human readable specs. > Whether or not it's harder to process locals vs. qualified elements is > debatable. > > [1] http://www.w3.org/TR/REC-xml-names/#ns-breakdown > > -aaron > > DevelopMentor > http://staff.develop.com/aarons > > > > ------------------------------------------------------------------ > The xml-dev list is sponsored by XML.org > <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: xml-dev-request@l...
|
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
|