- From: Dare Obasanjo <dareo@microsoft.com>
- Date: Wed, 12 Mar 2003 12:43:10 -0800
- To: "Danny Vint" <dvint@dvint.com>, <xmlschema-dev@w3.org>
I agree with your conclusions. ________________________________ From: Danny Vint [mailto:dvint@dvint.com] Sent: Wed 3/12/2003 12:07 PM To: xmlschema-dev@w3.org Subject: target Namespace and schema management I've got a different sort of question about namespaces. I understand their use for name collision avoidance, but what I'm interested in is their use for managing and identifying schema defintions. What is the best practice or op[tions for using a namespace to manage your schemas? A little background: I work for a standards organization, we have a public schema that we intend to be extended and reused by our members and other organizations. In a not to distant future, I expect to be reusing/importing information from other schemas into ours. How important (or not) is it to have a namespace assigned to our schema so it can support the type of reuse and extension we are talking about as well as allowing use to maintain our "stuff" separate from anything that we might want to import from somewhere else? I'm one of those old school SGML guys and I like my DOCTYPE with public identifer becasue it feels like I'm identifying exactly which spec/contract I'm expecting you to use (or that I worked to) and it is always with my document. I see the targetNamespace and the fact that this forces a data stream that conforms to it to identify the same namespace in the data. This feels like the closest I will get in schemas to a public identifier. If there is no targetNamespace, then there is no identification in the data stream of any standard identifier. At best I get a file location/name but that doesn't help universally identify my spec, and it is even watered down by the idea that this is "only a hint" as to where to find the file. That's my reasons for wanting the targetNamespace and feeling that it is wrong for an organization like mine to publish a standard without the associated namespace. Now my members were happy with this until a couple of weeks ago. It got pointed out that a stylesheet that worked for a stream based upon our DTD with no namespace use, will not work in our schema environement unless the stylesheet element match statements are prefixed with the namespace. Now because there is work involved with the adoption of this schema with the namespace, they want me to remove the targetNamespace in our final released schema. I can sympathize with the additional work issue, but no one is forcing them to give up our DTD environment and start using the schema, and besides I don't see why a little work for the added benefits should keep us from managing our standard and schema in the proper way. Am I offbase here or can I get some "added" support from this list to say that the targetNamespace is the best (maybe only) way we should go to answer the needs and desires I first stated? ..dan --------------------------------------------------------------------- Danny Vint ACORD 1 Blue Hill Plaza PO Box 1529 dvint@acord.org Pearl River, NY 10965 http://www.acord.org Voice:510:522-4703 FAX: 801-749-3229
Received on Wednesday, 12 March 2003 15:43:18 UTC