[
Lists Home |
Date Index |
Thread Index
]
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.
|
