RE: Namespaces - a couple nits and questions
Hi Danny, Here are my opinions on 3 and 4. 3) There *should* be a unique identifier for a format but namespace identification is different than format identification. It doesn't stop people from assuming they're the same, though. Of all the questions you brought up, this is the one I think is most important. Resist the temptation to merge these concepts. They seem friendly enough toward each other, but down the road they won't play nice. Why, I saw namespace running with scissors just last week. 4) The best way to do this, IMHO, is to have your namespace identifiers use a URI scheme that ties it to an organization. Namely, yours. And you're right in thinking it's a good idea to "own" your namespace. Of course there's no way to enforce that. On the subject of what URI scheme to use: Personally I use http: because I like RDDL and the knowledge that descriptions of my namespace could be retrieved if some agent/person wanted to. There's debate about the use of URL URIs for identifiers, though. My priority is accessibility of specs/documentation, and I know if I use http, even the simplest of agents could get at it. Good luck, Chris  Something analogous to what I'm calling "streamforms". See http://lists.xml.org/archives/xml-dev/200210/msg00717.html and http://lists.xml.org/archives/xml-dev/200210/msg01397.html  http://msdn.microsoft.com/library/en-us/dnglobspec/html/draft-nielsen-dime-02.txt  Although... my fiance used to work at Target... and she said they're trying to own the color red, so maybe there's some kind of definitive concept ownership registry out there...hmmm...check IANA. -----Original Message----- From: Danny Vint [mailto:dvint@m...] Sent: Monday, October 28, 2002 1:47 PM To: xml-dev@l... Subject: 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>
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format