W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2003

RE: target Namespace and schema management

From: Dare Obasanjo <dareo@microsoft.com>
Date: Wed, 12 Mar 2003 12:43:10 -0800
Message-ID: <B885BEDCB3664E4AB1C72F1D85CB29F804B7C9C1@RED-MSG-10.redmond.corp.microsoft.com>
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

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?


Danny Vint
ACORD                                       1 Blue Hill Plaza
                                            PO Box 1529
dvint@acord.org                             Pearl River, NY 10965

FAX: 801-749-3229
Received on Wednesday, 12 March 2003 15:43:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:09 UTC