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.



Peter,

No, I'm not.  There are a number of solutions, perhaps the best of which
I've just described in another post.  However, if we make <URI of namespace>
+ <complex type name> a URI, then we actually don't need new mechanisms -
although they'd be very useful.  It would be nice to coalesce xsi:type and
namespacing.

Matthew

> -----Original Message-----
> From: Peter Piatko [mailto:piatko@research.telcordia.com]
> Sent: Wednesday, August 29, 2001 12:30 PM
> To: Fuchs, Matthew; Ronald Bourret; xml-dev@lists.xml.org
> Subject: Re: Namespaces, schemas, Simon's filters.
> 
> 
> 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>
> >
> >
>