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