RE: Registered Namespace prefixes
Gavin: > Jeff: > > I don't know how one could assign ownership of a nonconflicting, > > short-sequence namespace identifier through any other > mechanism than a > > registry. > > My question is: why do you need to? > I always hear that > rationale that "we need > to mix and match arbitrary tag sets", but that only matters > if you do it > blindly, and somehow have a magical dispatch table keyed off > the prefix or > the URI. That's generally not the case, and generally not > open-ended even if > it exists (though you *could* do it using a registry). I agree. I'm not on about tag soup or namespace-aware processing. What I want to do is: 1) eliminate the need to resolve namespace prefixes -- simplifies tools -- reduces mistakes -- avoids overhead 2) eliminates any need to preserve prefix/nsID pairs during roundtrip processing of documents "But a registry is overhead!" I hear you shouting. True, but namespace prefix resolution mechanisms in tools are also overhead. Now, I'm not going to say that the way namespaces are now is a damning burden to bear, but if something's going to be foundational, then any complexity at the base level risks being propagated upward through each layer resting on top. > If that's not true, you will have some form of > convention/agreement in place > that let's you know what to expect.... you'll know what a > name:space is, and > an html:p. In that case, the registry is largely superfluous, > because if you > and I have a convention to use foo: prefixes in our data > interchange, why > should we care if some other party uses it? First of all, basing any logic on ns prefixes (as they exist now) is a risky deal, convention or no. Second of all, we do care (most of us anyway) about the associative integrity of a namespace id. Think not? Most namespace ids are based on URLs with domain names at their root. If you're running around adding associations to namespace URLs starting with "http://www.microsoft.com", I think you had better hope your associations don't become so prevalent that a certains company's attorneys get wind of it. Nothing (but common sense) prevents you from polluting the associative space of namespace ids rooted at MS's web address, at least until you attain a certain level of notoriety. > If we expect to > deal with their > data at some point, we might, but we might at that point also > negotiate the > use of a different prefix. Again, even with convention, doing this with 'unregistered' prefixes is risky business, IMO. But yes, it can be done. > For vocabularies that people *do* care enough about to > standardize, there are > already registration vehicles in place. Like OASIS? I suppose. > > > Just to hammer this nail one more time: there's no need to > 'consult' the > > registry. > > Your registry is > really just for > humans to use? I think that's a good way to put it, although I wouldn't rule out things like a basic lookup/dump web service. >That might help people who write standards. Merely recommending, my friend. Merely recommending.
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