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


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>




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