Re: Namespaces, schemas, Simon's filters.

[Peter Piatko <piatko@research.telcordia.com>]

Are you suggesting that local elements be annotated with an xsi:type
attribute (perhaps even added in at some post-processing stage)?  This is a
new syntax as far as the XML Namespace rec is concerned.  ;-)  Then deciding
the namespace of an element becomes a two-stage process---check for the
prefix and then check for the xsi:type attribute.  An important point is
that the second check is *not* part of the current Namespace rec.

I'm being nitpicky here, but according the Namespace rec: "An XML namespace
is a collection of names, ***identified by a URI reference***" [1]
(asterisks mine).  If the complex type name is in a namespace, then <URI of
namespace> + <complex type name> should technically evaluate to a URI, if
indeed a complex type creates its own namespace.  This is just an
observation, BTW.  Maybe this is all described somewhere in the XML Schema
rec.

In any case, somehow I feel I am not quite following what you are saying?

Thanks,

Peter

[1] http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-namespace

----- Original Message -----
From: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>
To: "Ronald Bourret" <rpbourret@rpbourret.com>; <xml-dev@lists.xml.org>
Sent: Wednesday, August 29, 2001 2:12 PM
Subject: RE: Namespaces, schemas, Simon's filters.


> 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.
>
> Matthew
>
> > -----Original Message-----
> > From: Ronald Bourret [mailto:rpbourret@rpbourret.com]
> > Sent: Monday, August 27, 2001 11:23 PM
> > To: xml-dev@lists.xml.org
> > Subject: Re: Namespaces, schemas, Simon's filters.
> >
> >
> > Peter Piatko wrote:
> > > I think it is pretty clear that the syntactic sugar of the
> > Namespace rec
> > > doesn't handle hierarchies all that well, and that Per-Element-Type
> > > partitions introduce such hierarchies (of at least one
> > level anyway).  So I
> > > feel that the options are (a) enhance the syntax or (b)
> > simplify (i.e.
> > > flatten) the interpretation of what namespaces are.  The
> > current situation
> > > is just confusing.
> >
> > Agreed, although it is mostly confusing because we keep
> > trying to impose
> > things on namespaces that just aren't there. I've many a mini-career
> > trying to debunk these and I still get tripped up...
> >
> > > Option (b) implies that an identifier might map to multiple
> > types.  I think
> > > the question boils down whether this ok or not.
> >
> > In the end, I think you have to allow it. My gut tells me that the
> > alternative could get quite nasty. Besides, one of the nice
> > things about
> > XML is that it does let you do your own thing, even if that
> > thing isn't
> > always the best thing to do.
> >
> > -- Ron
> >
> > -----------------------------------------------------------------
> > 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>
> >
>
> -----------------------------------------------------------------
> 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>
>
>