RE: Namespaces, schemas, Simon's filters.

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

Peter,

Yes, if we coalesce complexTypes as a kind of namespace, then xsi:type can
be construed as redundant and we can have a means of getting all the typing
information (which becomes namespacing information) into the instance.  And
yes, xmlcont (or whatever it would end up as) would be a means of doing so.

I agree with your first paragraph, and NUNs are an essential part of that.  

To a large extent, this is an application of Occam's razor - Schema
currently has namespaces as a scoping abstraction and complexTypes as an
orthogonal scoping abstraction, as well as elements (through their ability
to contain anonymous complexTypes).  I think we'd certainly be better off to
collapse them.  Every time you have orthogonal ways of doing the same thing,
you end up with a cartesian product of cases.

Matthew

> -----Original Message-----
> From: Peter Piatko [mailto:piatko@research.telcordia.com]
> Sent: Thursday, August 30, 2001 6:59 AM
> To: Fuchs, Matthew; xml-dev@lists.xml.org
> Subject: Re: Namespaces, schemas, Simon's filters.
> 
> 
> Hi,
> 
> If we had a mechanism for making <URI of namespace> + 
> <complex type name> =
> <another URI> then I believe some measure of compromise might 
> be reached,
> since we can all finally agree that local names belong in 
> *some* namespace,
> and this particular namespace seems a reasonable place to put 
> them.  The
> question remains if this information should be represented in 
> an instance
> document (I'd say yes, if practical), and if so, how.  The existing
> namespace syntax would probably break under the load, as 
> instance documents
> would expend more characters on namespace declarations than 
> actual data.
> 
> Is the solution you refer to here the "xmlcont" pseudo-attribute (I'm
> offline right now, so I can provide a pointer)?  I feel that 
> might get us
> part of the way there.  Perhaps if we had some way of declaring
> subnamespaces?  I'm thinking of something like the following 
> (in a truly
> loose syntax):
> 
> xmlns:g="<some global URI>
> ....
> xmls:g:s="g#type::sub"
> ....
> <g:s:foo/>
> ....
> 
> I have to admit that I haven't given this a whole lot of 
> thought, so maybe
> the whole idea is bonkers.  ;-)
> 
> On a somewhat unrelated note, I think I now understand your 
> concern about
> xsi:type.  If the namespace of the local element is made 
> explicit in the
> instance document, xsi:type becomes redundant, right?
> 
> Thanks,
> 
> Peter
> 
> ----- Original Message -----
> From: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>
> To: "'Peter Piatko'" <piatko@research.telcordia.com>;
> <xml-dev@lists.xml.org>
> Sent: Wednesday, August 29, 2001 4:24 PM
> Subject: 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>
> > >
> > >
> >
>
> -----------------------------------------------------------------
> 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>
>
>