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