RE: Namespaces, schemas, Simon's filters.

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Richard,

I just posted a response to Tim Bray which I think also covers this.
Basically,
1) I think the current mechanism is insufficient, therefore I'm against
premature solutions.  Keeping local elements out of the namespace
mechanism's purview allows more freedom on how to roll them in later.
2) The default mechanism at least distinguishes the two cases of local and
global, and software can exploit that.  Since the global case is the status
quo ante, software which previously understood qualified elements and didn't
understand unqualified elements still can function.  If local elements are
put in their parent's namespace, then existing software will break in
strange ways, depending on characteristics of the schema.

Matthew

> -----Original Message-----
> From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk]
> Sent: Thursday, August 23, 2001 2:31 PM
> To: Fuchs, Matthew
> Cc: xml-dev@lists.xml.org
> Subject: 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
> 
> -----------------------------------------------------------------
> 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 subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>