Re: [regrep] FW: Namespace management

[Chiusano Joseph <chiusano_joseph@bah.com>]

David, please see comments below.

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

Which ties a construct to a specific registry (which is valuable in many
cases). But what about cases where the constructs that comprise a
vocabulary with an assigned namespace identifier are stored in multiple
registries?  Doesn't this defeat the whole purpose of federation?  This
seems more restrictive to me than namespaces might even now be seen.

- Joe

David RR Webber - XML ebusiness wrote:
> 
> 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<
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