OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] FW: Namespace management


<Quote>
I won't tell you what's the best way of implementing it in the spec, but
creating another entity is not an option to me. The data model of the
Registry is already quite complex. Maybe you can use a classification
schemas that would indicate that this particular object must be unique
in this particular way and just hardcode it in the product.
</Quote>

Absolutely Max. If we were to create a "best practice" or binding that
enabled elements/attributes/datatypes to be registered as
RegistryObjects (working with the Content Management mechanism), one
could simply associate these artifacts with their pertinent namespace
using classification, or association.

Joe


Max Voskob wrote:
> 
> David and all,
> 
> I think it's not about prefixes or how you declare your namespaces in the
> instance documents.
> 
> 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.
> 
> I won't tell you what's the best way of implementing it in the spec, but
> creating another entity is not an option to me. The data model of the
> Registry is already quite complex. Maybe you can use a classification
> schemas that would indicate that this particular object must be unique in
> this particular way and just hardcode it in the product.
> 
> Cheers,
> Max
> 
> ----- Original Message -----
> From: "David RR Webber - XML ebusiness" <Gnosis_@compuserve.com>
> To: "Chiusano Joseph" <chiusano_joseph@bah.com>
> Cc: "MACIAS Paul" <PMACIAS@lmi.org>; "OASIS_RegRep (E-mail)"
> <regrep@lists.oasis-open.org>
> Sent: Monday, March 03, 2003 6:33 PM
> Subject: Re: [regrep] FW: Namespace management
> 
> Joe,
> 
> I'm very troubled that this whole namespace fixation is
> chasing after a false god.   I hope we can head this
> off before it grows to be a vast beast that
> threatens to consume us!
> 
> The system I have envisioned for the CAM mechanism
> does away with the need to have strict uniqueness,
> while guaranteeing that WITHIN YOUR OWN CONTEXT
> you are able to express the necessary semantic
> resolution that you require.
> 
> I think our Federal XML WG folks need to take heed
> here - before they create a bureau of namespaces.
> 
> I stressed the above to show how this is different.  I guess I
> never bought into the premise from the W3C that
> you HAD to have a unique prefix on your XML, else
> it would not "work".   I find this flawed, and further more
> users react badly when asked to add prefixes to tags,
> and mapping software reacts even worse when asked
> to manage and move content so labelled.
> 
> Here's how the adaptive approach works instead - and
> I'll talk about real world parallel in live systems to
> illustrate this too.
> 
> A registry server is identified to a federation server,
> and within your local context (an assembly) it is
> assigned an alias (some short character sequence)
> with an associated physical address to the interface
> to that registry.
> 
> Now I use that alias as a prefix to a UID value, to
> identify the reference I need as a content cross-reference
> within my CAM template.
> 
> Now of course - I do not care that someone else is
> using the exact same alias for some other registry
> in their CAM document elsewhere.
> 
> This could only be a potential issue if another
> assembly document included into it both mine
> and the other assembly.  But even then - using the
> include as a prefix - negates the collisions.
> 
> The power of this system is that anyone can
> call any <tagsoup> item whatever they need to
> in their local context and usage, but denote it
> in the content reference:
> 
> <thisworks>
>    <mine>
>        <city/>
>    </mine>
>    <his>
>       <city/>
>    </his>
>    <yours>
>       <city/>
>    </yours>
> </thisworks>
> 
> and then
> 
> <contentreferences>
>    <registry alias="mine" address="http://foobar.com/port:1000"/>
>    <registry alias="yours" address="http://somebar.com/port:9000"/>
>    <content name='//mine/city' reference="mine:UID010001"/>
>    <content name='//his/city' reference="mine:UID078901"/>
>    <content name='//yours/city' reference="yours:UID055501"/>
> </contentreferences>
> 
> Bottom line is this simple and clean means makes the CAM
> system a breeze when including content from multiple sub-assemblies.
> Essentially you never need to worry about collisions in the underlying
> content fragments - because you can always resolve references.
> 
> Of course by doing this we remove the need for namespace police,
> and even the need to create complex mechanisms in our ebXML
> Registry implementations to support the namespace police.
> 
> Effectively the federation server is able to act as the domain
> locator for aliases and content references.  This is a much
> cleaner simpler and self-managing system.
> 
> In real live systems- notice there is nothing to stop me
> have three companies all called "IBM Corporation",
> one is the Italian Bread Makers, another is the
> Industrial Brick Makers, and the other is the
> Intra-Banking Machines.   Reference the state business registry
> to find out which one does what.
> 
> Cheers, DW.
> =====================================================
> Message text written by Chiusano Joseph
> >
> Paul,
> 
> This is directly related to the e-mail I cross-posted from XML-DEV 2
> evenings ago (on a Namespace Management function). I am hoping that we
> can include this in the v4 Registry specs, or in a best practice or
> binding-type document.
> 
> More details:
> 
> <QuoteFromJessica>
> I am researching the current ability and/or purposed requirements of
> ebXML and the Federal Registry regarding namespaces.
> My specific interest is whether there is the ability or requirement for
> a Registry to manage namespaces for an organization
> to ensure at an enterprise level that a namespace is unique (i.e. two
> different organizations are not using the same URI).
> </QuoteFromJessica>
> 
> No explicit ability in ebXML registry (yet).
> 
> <QuoteFromJessica>
> Additionally, I want to know whether any automated governance is being
> built-in to the Registry to help organizations
> create their URIs so that they stay within the requirements of their
> organization (i.e. an organization has defined that
> they only will use one enterprise namespace, the system would deny a
> division of the organization the ability to register
> their own URI).
> </QuoteFromJessica>
> 
> This quote started with governance and gravitated toward security - I'll
> address it from were it wound up (security). If a namespace identifier
> were a RegistryObject, this would simply be done using the access
> control mechanisms defined in the Registry specs.
> 
> - Joe<
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> 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]