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