[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Namespace Manager Proposal] FW: XMLNDR [Broken URL] RE: XMLNDR PURLs, Handles, URLs, URNs & Namespaces
Back in January 2002 I submitted a proposal to our list for a "Namespace Manager" function. The archive link is forever gone, and Robin Cover asked me to send him a summary of the highlights of that proposal. I am sending this to refresh our collective memories of this proposal, as we look toward version 4.0 (hint hint;) Ironically (as you can see from the right side of the e-mail subject) I sent the archive URL in support of a discussion on persistent identifiers on the "U.S. Federal XML Naming and Design Rules" listserv, and subsequently discovered that it was a broken link.:p To those in the U.S.: Happy Labor Day weekend. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com -----Original Message----- From: Chiusano Joseph Sent: Friday, September 02, 2005 4:19 PM To: Robin Cover Cc: Robin Cover Subject: RE: XMLNDR [Broken URL] RE: XMLNDR PURLs, Handles, URLs, URNs & Namespaces Hi Robin, > Joe: can you send me the text (or some portion of it)? I'm the > self-appointed Moses of the Eleventh Commandment Sure - at this point I believe the link is unretreivable. Here is the gist of the Namespace Manager proposal: A Namespace Manager function within the ebXML Registry standard would provide a mechanism by which namespaces (both "functional" namespaces and XML namespace identifiers) can be managed and evolved within ebXML Registry. Functional namespaces can be represented as RegistryObjects that are managed using the native lifecycle capabilities of ebXML Registry. These namespaces can also be classified using the native mechanisms for classifying RegistryObjects. XML namespace identifiers can be associated with functional namespaces as Slots on the functional namespace RegistryObject. Associations can then be made between the XML schemas and XML documents in which the namespace is used, either as a targetNamespace or a non-targetNamespace. Association types can be used to differentiate between these 2 usages (e.g. "hasAsTargetNamespace" or "hasAsNamespace"). Now that such associations are made, the following types of operations are possible: (1) Mass update of namespace identifiers: If a namespace identifier needs to be changed (e.g. from URL to URN, or the identifier itself but not the identifier type), the update can be made to the corresponding functional namespace RegistryObject (the XML namespace identifier slot), and propagated to all associated XML schemas and XML documents that the user has access to. (2) Namespace comparison: Fine-grained XML artifacts (e.g. elements, attributes, datatypes) from 2 (or more) different functional namespaces can be compared, perhaps for harmonization purposes (i.e. discover degrees of similiarity/differences in multiple areas, such as: artifact names, artifact datatypes, etc.) (3) Access control: Users may be given access rights (through the XACML binding or the ebXML Registry "native" access control mechanisms) according to functional namespaces. For example, a user that does not have access to a given functional namespace cannot access any RepositoryItems (e.g. XML schemas, XML documents) in which that namespace is used (i.e. that have the XML namespace identifier associated with that RegistryObject either as targetNamespace or non-targetNamespace). (4) Event notification: Users may subscribe to a functional namespace in order to be notified when there are any additions/updates/deletes (as specified in the subscription) to XML artifacts in a given functional namespace. ...and more. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Robin Cover [mailto:robin@oasis-open.org] > Sent: Wednesday, August 31, 2005 9:03 AM > To: Chiusano Joseph > Cc: Robin Cover > Subject: Re: XMLNDR [Broken URL] RE: XMLNDR PURLs, Handles, URLs, URNs > & Namespaces > > > Joe: can you send me the text (or some portion of it)? I'm the > self-appointed Moses of the Eleventh Commandment > > "Thou shalt not break any links" > > so this concerns me... > > - Rabbi Robin ben Moshe Sinaitici > > ---------- > > On Wed, 31 Aug 2005, Chiusano Joseph wrote: > > > Oops - I just found out that the URL I provided is now > broken; I will > > try and find out from OASIS how to retreive it from their > > architectures (it's broken in the OASIS ebXML Registry > listserv public > > archives as well). Sorry for the inconvenience. > > > > Joe > > > > Joseph Chiusano > > Booz Allen Hamilton > > O: 703-902-6923 > > C: 202-251-0731 > > Visit us online@ http://www.boozallen.com > <http://www.boozallen.com/> > > > > > > > > ________________________________ > > > > From: Chiusano Joseph > > Sent: Wednesday, August 31, 2005 9:37 AM > > To: 'listserv@fed-xml-ndr.core.gov' > > Subject: RE: XMLNDR PURLs, Handles, URLs, URNs & Namespaces > > > > > > FWIW: Back in January 2002, I proposed the inclusion of > a "Namespace > > Manager" function to the OASIS ebXML Registry standard, that would > > make all of this easier (can update namespace identifiers > on the fly > > and have them propagate to all pertinent documents, etc. - with all > > the necessary precautions and controls). > > > > See > > http://lists.oasis-open.org/archives/regrep/200201/msg00061.html > > <http://lists.oasis-open.org/archives/regrep/200201/msg00061.html> . > > > > This may make it into ebXML Registry Version 4.0, which > we're in the > > early stages of thinking about now that Version 3.0 became an OASIS > > standard several months ago. > > > > Joe > > > > Joseph Chiusano > > Booz Allen Hamilton > > O: 703-902-6923 > > C: 202-251-0731 > > Visit us online@ http://www.boozallen.com > <http://www.boozallen.com/> > > > > > > > > ________________________________ > > > > From: Gary Poindexter > > [mailto:gary.poindexter@xmllegal.org] > > Sent: Wednesday, August 31, 2005 9:28 AM > > To: listserv@fed-xml-ndr.core.gov > > Subject: RE: XMLNDR PURLs, Handles, URLs, URNs & Namespaces > > > > > > > > I agree with Todd with the following caveat: Every schema must > > have a version so technically I could change > the version of > > my schema and use the same namespace. I prefer the precision of the > > version being in the namespace name for the reasons Todd > mentions - see > > the following comment. > > > > > > > > If URLs are used for namespaces (my preference) then I would make > > it a "must" that the URL be the location of the schema. I find it > > very annoying and time consuming when a URL is used and it points to > > a generic web site or no web site at all - which > makes it a > > URN that looks like a URL. If the schema is not at the > location I have > > to begin a search that can be very time consuming. > > > > > > > > gary > > > > > > > > gary poindexter > > > > <xmlLegal> > > > > Mobile: 414-467-8222 > > > > Fax : 770-216-1633 > > > > Email: gary.poindexter@xmllegal.org > > <mailto:gary.poindexter@xmllegal.org> > > > > > > ________________________________ > > > > > > From: Winchel 'Todd' Vincent III > > [mailto:Todd.Vincent@xmllegal.org] > > Sent: Monday, August 29, 2005 1:49 PM > > To: listserv@fed-xml-ndr.core.gov > > Subject: Re: XMLNDR PURLs, Handles, URLs, URNs & Namespaces > > > > > > > > > > > > <Owen> > > > > > Thus far you have not convinced me that the concept of > > "freezing" is > > > consistent with the concept of "change". > > > > </Owen> > > > > > > > > :-) > > > > > > > > Freezing a namespace/schema means you cannot change the > > namespace/schema. It does not mean you cannot create a new > version of > > the schema for changed requirements. > > > > > > > > Suppose I have: > > > > > > > > us:irs:forms:2005:1040:01 > > > > > > > > Once I publish this schema, I can expect a class of instances to > > be created based on it. Let's assume, 100,000 instance documents > > are created based on the schema. > > > > > > > > In 2005, I discover a mistake in the 01 schema, so I change it to: > > > > > > > > us:irs:forms:2005:1040:02 > > > > > > > > Again, I create 100,000 instances based on this schema. > > > > > > > > In 2006, I create a new version for the new year: > > > > > > > > us:irs:forms:2006:1040:01 > > > > > > > > > > > > Again, I create 100,000 instances based on this schema. > > > > > > > > I now have 300,000 instances of a Form 1040, each of which is > > similar, but different. Each instance, > fortunately, is clearly > > identified (from a schema validation perspective) as 2005 > 01 version, > > 2005 02 version and 2006 01 version. From a schema validation > > perspective and a namespace perspective, there is no way to > confuse the > > instances. > > > > > > > > However, if I create 3 schemas using the same namespace and create > > 100,000 documents each for all three schemas: > > > > > > > > us:irs:forms:1040 > > > > > > > > Then I have 300,000 instances with the same namespace, but 100,000 > > instances, 100,000 instances, and 100,000 instances are different. > > If you look at the instance document alone, there is no technical > > means of determining one from the other. Even a false validation > > won't give you a hint. (This is similar to detaching the stylesheet > > from the data, by the way.) > > > > > > > > xsi:schemaLocation is not helpful (a) because it is optional in an > > instance and (b) because it can and probably > will point > > to a path that isn't good or could be wrong (i.e., it is > unreliable). > > Namespaces aren't optional and are 100% reliable (if you want to > > validate against a schema with the same namespace.) > > > > > > > > The namespace of all instances in the class must match the > > namespace of the schema used to validate it. If I have three > > namespaces for three schemas, I can precisely determine the class of > > instances for every document in the 300,000. If I have one > namespace > > for three schemas, I have no idea which of the three schemas is > > associated with any one of the instances. Freezing > namespaces/schemas > > (i.e., not changing the schema or reusing the namespace > once an instance > > has been published) ensures good change management when > changing from > > one schema to the next. > > > > > > > > From a technical perspective, the issue is crystal clear. You > > have a decision: > > > > > > > > (a) a regime where one namespace = one schema and one class of > > instances > > > > > > > > or > > > > > > > > (b) a regime where one namespace = multiple schemas and multiple > > classes of instances > > > > > > > > If this does not make sense from a technical perspective, then ask > > yourself, "Is ambiguity generally > good or bad in > > technology?" Between (a) or (b) which is more or less ambiguous? > > > > > > > > Thanks, > > > > > > > > Todd > > > > > > > > =========================== > > Winchel "Todd" Vincent III > > <xmlLegal> http://www.xmllegal.org/ > > Phone : 404.822.4668 > > Fax : 770.216.1633 > > Email : Todd.Vincent@xmllegal.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]