[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] FW: Namespace management
<Quote1> However - in the "wild" you have to plan for prefix collision, and have the abilty to simply move around that. Hardwiring everything with prefixes only sets you up for a fall when prefix collision occurs. </Quote1> I believe the main issue is with *construct collision*, not prefix collision. Prefixes are syntactic sugar, and are not even passed to the Infoset. <Quote2> All the namespace is doing in this instance is providing the means to associate a collection of group members. </Quote2> And this is a very important thing. Joe David RR Webber - XML ebusiness wrote: > > Max, > > OK - I think I did clarify this issue in my reply to Matt. > > Yep - discovery is a great use case - and we can enable that > with simple extrinsic representation - using keywords to capture > what the namespace is enabling + text description + context > declarations where appropriate - so that people can find > and re-use those tools. > > However - in the "wild" you have to plan for prefix collision, > and have the abilty to simply move around that. Hardwiring > everything with prefixes only sets you up for a fall when > prefix collision occurs. Also versioning is a key requirement > and again simple prefix does not include version selection. > > So I come back to a blend - of using namespaces for tools, > and using CAM style approach to capture the business use > of the schemas. OK - so yep - you do not have to use CAM - > you can use your own format to capture semantics about the > schemas - that will enable searching (hint - the CAM header > section can be "lifted" to do just that). > > As far as the registry is concerned - there's some extrinsic > content - and you can search on it. All the namespace is > doing in this instance is providing the means to associate > a collection of group members. > > Notice also if you want to do this: > > <Message> > <ShipAddress> > <include "OASIS-CIQ-address" version="1.1"/> > </ShipAddress> > <OrderItems> > <Item> > <include "UBL-Item" version="2.01"/> > </Item> > </OrderItems> > <Message> > > Having the lower level of content "sub-assemblies" > un-encumbered by namespaces issues and potential > prefix collisions great simplifies this cut and paste approach. > > Thanks, DW. > ====================================================== > Message text written by Max Voskob > > > Imagine an organisation where 25 departments are creating different XML > documents and formalise them with all sorts of documentation including XML > Schemas. How do they ensure that the new namespace ID they've just come up > with is not already used somewhere else within the organisation? > Sure, they can write a 25 page guide how to name their namespaces (if they > can't they email me and I'll write one for them :), but it's hard to > reinforce. > If I can go to my enterprise registry or its federated node (not sure I use > the right wording here) and find out if the NS is in use, by who, where the > schemas are and all that sort of information. > < > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]