[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Namespaces, schemas, Simon's filters.
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@r...] > Sent: Thursday, August 30, 2001 6:59 AM > To: Fuchs, Matthew; xml-dev@l... > 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@c...> > To: "'Peter Piatko'" <piatko@r...>; > <xml-dev@l...> > 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@r...] > > > Sent: Wednesday, August 29, 2001 12:30 PM > > > To: Fuchs, Matthew; Ronald Bourret; xml-dev@l... > > > 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@c...> > > > To: "Ronald Bourret" <rpbourret@r...>; > > > <xml-dev@l...> > > > 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@r...] > > > > > Sent: Monday, August 27, 2001 11:23 PM > > > > > To: xml-dev@l... > > > > > 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> > >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|