[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] FW: Namespace management
Chiusano Joseph wrote: ><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. > +1 on Joe's suggestion of defining a binding to handle the namespace management use cases. I have assumed all along that name space management would be handled by defining a binding for XML Schema to ebXML Registry (just like we define a binding for WSDL, HL7 etc.). Such a binding would define how namespaces get automatically cataloged within the registry and thus become automatically searchable. Part of such a binding would be the definition of template ad hoc queries that cover common namespace discovery use cases. Such a binding would be another best practice paper in my opinion rather than part of ebRIM and ebRS specs. > >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> >> >> -- Regards, Farrukh ---------------------------------------------------------------- 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]