RE: [xml-dev] Namespaces - a couple nits and questions

["Dare Obasanjo" <dareo@microsoft.com>]

Good questions. 
 
There's a general point I want to make is that you seem to be using the term "namespace" and "schema" (specifically an XSD schema) interchangeably. They aren't the same thing. 
 
A1) Without more knowledge of the target domain I hesitate to give you any advice in this regard. I do believe that the guiding principles should be i.) A single entity controls the contents of each namespace [although the lines become blurry at the departments within a company level] ii) the items in the namespace all are parts of the same whole. 
 
A2) Every file format (heck, even every technology) I've ever seen has been versioned. However there is no standard way for adding versioning semantics to namespaces although some favor the 
 
   http://my.domain.example.org/product/[year/month][/area]
 
format for namespace URIs which can be used for providing application specific versioning semantics. 
 
A3) I completely disagree with this. Why tie just one document to the namespace? What schema language will you use? Even if you pick one, which version of the schema language do you choose? What if prose descriptions are needed for your namespace but validation using a schema is typically unecessary for some use cases? There are more reasons why this is a bad idea but you get the idea. 
 
However, some people in the W3C as well as the RDDL camp (http://www.rddl.org) seem to think that some sort of "namespace document" which may contain a repository of information about the namespace including prose descriptions, schemas, stylesheets, etc. 
 
A4) If you are asking if there is any way to prevent someone using xs:redefine on the items in your schema then the answer is no. By the way, Yes, this is a misfeature. 

	-----Original Message----- 
	From: Danny Vint [mailto:dvint@mindspring.com] 
	Sent: Mon 10/28/2002 10:46 AM 
	To: xml-dev@lists.xml.org 
	Cc: 
	Subject: [xml-dev] Namespaces - a couple nits and questions
	
	

	My organization is starting to apply namespaces to its various specs. I
	know the general discussion and likes/dislikes about them, but I don't
	think I have seen anyone address them from the following viewpoint, so I'd
	be interested in some discussion.
	
	There seem to be the following views or ways to use a namespace:
	
	1) Original spec seems to see them as a way to disambiguate two elements
	with the same name - plain and simple no semantics or other
	overhead/overloading of their use.
	
	2) In schemas, they with some of the attributes in <Import> seem to handle
	the same functionality of the DOCTYPE and its PUBLIC and SYSTEM identifiers.
	
	3) Coming from the OO world seems to be the notion of domains for
	vocabularies. We have a banking domain, an insurance domain, a
	manufacturing domain, and legal domain. The element <title> might be used
	in all of these domains, but I should identify the domain that it comes
	from by using the proper namespace to identify its definition.
	
	4) A namespace as a owned resource that should be protected from other
	groups and organizations stepping on it. This came up in regards to use of
	<redefine> to add or enhance my organizations definitions with company
	unique information or requirements.
	
	I work for ACORD an Insurance industry standards group and when we had a
	general meeting on namespace usage all of the above definitions and uses
	were brought up. I personally think at least #3 is a different sort of use
	for namespaces when we need to answer the following questions, and that #4
	is a rather restrictive way to view their use when trying to extend a
	specification.
	
	Questions:
	
	Q1) I have 3 different standards within our organization and they may have
	the same elements and some of the same structures. How should namespaces be
	used to identify these particular standards? Should I have one Insurance
	domain namespace?
	
	Our standards are currently divided along the lines of Life, Property,
	Causality and Surety, and Reinsurance, should I have different namespace
	for each? At least one of these specs has been split into 2 parts, one
	being the payload (business/Insurance data) and the other being a framework
	or messaging structure that includes the payload portion.
	
	Should this be all one namespace or should they be at least 2 namespaces?
	Should the included portion be identifiable by 2 namespaces (one namespace
	being when used standalone and the other when used in the message structure)?
	
	Q2) Should a namespace be versioned? This is more for file and element
	identification which fits #1 and #2, but seems contrary to #3.
	
	Q3) Should a namespace act like a PUBLIC Identifier and be able to identify
	a specific file and version of a schema (lets ignore DTDs for now)? This
	doesn't mean that I would be able to look up the URL and find the schema,
	but that there should be a unique name/namespace for each version.
	
	Q4) Should my organization be "protecting" our namespace and make sure that
	no one <redefine>'s that namespace to be something unique for them?
	
	..dan
	---------------------------------------------------------------------------
	Danny Vint
	http://www.dvint.com
	
	
	    
	
	
	-----------------------------------------------------------------
	The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
	initiative of OASIS <http://www.oasis-open.org>
	
	The list archives are at http://lists.xml.org/archives/xml-dev/
	
	To subscribe or unsubscribe from this list use the subscription
	manager: <http://lists.xml.org/ob/adm.pl>