OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespaces, schemas, Simon's filters.



>Actually, while I've argued as to why making local elements unqualified is a
>good thing from the point of view of what local elements are, no one has
>given a similar argument for why local elements should be qualified.  The
>arguments in favor of qualifying them have been simply "I don't like
>unqualified elements because I can't use the namespace to uniquely identify
>the element" - when namespaces fail to uniquely identify different local
>elements anyway.

A fair question.  To elaborate it a bit, the argument is that if you
need the containing-element context to identify the element, then it
makes no difference whether it's qualified or not because you can only
interpret it in that context.

Two reasons spring to mind:

 - Even if it doesn't tell you exactly what it means, it still tells
   you where to go to find the answer.  It's immediately clear that
   it's *one* of the the foo elements from the xyzzy namespace.

 - Often (take that with a pinch of salt: like most people, I've only
   written a few schemas) all the foo elements in the xyzzy namespace
   *mean* the same thing.  It's just that some of them are restricted
   in different ways because of the context.  For example, in my
   serialization of the XML infoset, the <children> child of the
   <documentTypeDeclaration> element and the <children> child of
   the <element> element are both in some sense the same thing, but
   the allowed content is different and by using local elements
   I can give them different content models and get better validation.
   After all, if they weren't in some way the same I wouldn't have given
   them the same name.

-- Richard