Cart
[Home] [By Thread] [By Date] [Recent Entries]
On 20 May 2001 07:19:00 +0100, Martin Gudgin wrote: > So what would you do with the following XML document? > > <p:book xmlns:p='urn:x1'> > <p:title>The Hobbit</p:title> > <p:genre>Fantasy</p:genre> > <p:author> > <p:title>Dr</p:title> > <p:familyName>Tolkien</p:familyName> > </p:author> > </p:book> > > All the elements are namespace qualified. How do you distinguish between the > two title elements? The simple answer is to manage my own name conflicts, and not use p:title twice with different meanings. This would seem (to me) especially obvious in the context of XML Schema where type is everything - the only reason this example works is that p:title is just simple text. If the two titles were of genuinely different types, there's be a much larger problem. RELAX provides for this by permitting context-dependent content models, but I don't think the RELAX documents encourage the practice you're proposing. > Or take XSLT. xsl:param can appear in two places; as a child of > stylesheet/transform or as a child of template. It *does not* mean exactly > the same thing in both places. When it's a child of template the parameter > is local to that template, when it is a child of stylesheet/transform the > parameter is global. How does an XSLT processor distinguish between these > two cases? It treats xsl:param as locally scoped and checks the parent. Context-dependency matters in a large number of XML use cases. The particular kind of context-dependency you are proposing (unqualified elements belonging to their parent context) is not supported by the Namespaces spec itself, and I think you're making enormous assumptions about the kind of processing required to handle them without considering the impact on exchange with other users who will not make those same unsupported assumptions. > I think my argument is that local scoping may well be in effect *anyway*. > People are already using it without realising it. I think that making > locally scoped elements unqualified acts as a trigger saying 'look at my > parent! look at my parent!'. But Namespaces in XML already defines scoping explicitly, and says "look at my parent for xmlns declarations!" not "look at my parent for its namespace URI!" > I am sharing them in the markup. If the following document appeared at your > door one night, what would you do? > > <p:person xmlns:p='urn:x2' xmlns='' > > <name>Martin</name> > <age>33</age> > </p:person> I'd wonder why Martin Gudgin was sending me documents which seem to demonstrate a serious lack of understanding about namespaces, even though he appears to be three years older than I am. As a human, I'm happy to read past namespace declarations and take guesses. Most programs aren't nearly so forgiving. > You'd take one look at the namespace name and local-name of the document > element and tell it to get lost because you didn't know how to process it. No, not necessarily. I'd look for a RDDL document at the URI specified for p, and realize that the sender likes perverse URNs in addition to bizarre usage of elements with no namespace URI. If you'd dropped a RDDL document at the URI with some kind of explanation of what you were up to, I might have used kinder words than bizarre and perverse and maybe written some code to cope with your usage. > So, I'm curious, what do you do now if you see an element in no namespace? I assume that they were created by people using vocabularies which have no namespaces. A _lot_ of people use XML without using namespaces _at all_. I taught an XML Interoperability course at the Washington DC ACM last week. I had thirty-five students. I asked how many had created XML vocabularies - about twenty-five. (Only two are in production settings, though.) I asked how many had used a namespace identifier on their vocabulary - one. People were genuinely aggravated by my suggestion that they define namespaces even in documents which use only one vocabulary. Seeing no namespace applied tends to remind me of that approach, and I figure it just combined with a namespace-using approach. > And I think the shortcut has already been taken. If anything, this makes it > safer by not fooling people into thinking they know how to process an > element based entirely on its local name and namespace name. So far as I've seen, you're the only person taking this particular shortcut. I'd be interested to hear if there's anyone else who (independently) came to this approach.
|
