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.



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>
>
>