Re: [regrep] FW: Namespace management

[Max Voskob <mvoskob@msi.com.au>]

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>