Lists Home |
Date Index |
> From: Gavin Thomas Nicol [mailto:email@example.com]
> FWIW. I think this is a reasonable goal... couldn't agree
> more in fact.
Dang! Just when I though I had succeeded in alienating all of xml-dev...
> > Does it make the meaning of that universal name unique? No.
> Right, and this is my point: the registry is just overhead
> because of this. At
> the end of the day, despite any claims to the contrary,
> without a significant
> change in programming models, local context, and local
> interpretation is
> *all* you have.
Urgh. I don't understand why you say this. I do agree that the registry
would be overhead (though less than you would think, see below), but I don't
know how one could assign ownership of a nonconflicting, short-sequence
namespace identifier through any other mechanism that a registry.
> Tag vocabularies can work just as well by
> convention as they
> can by consulting a global registry.
Just to hammer this nail one more time: there's no need to 'consult' the
registry. There would be nothing useful there as far as document processing
goes. All you need is to be able to make a reasonable assumption about the
uniqueness of the identifier. Say it's of a certain format: therefore you
The registry functions outside the context of document processing. It is
merely a uniqueness assurance validator, along with information about who
"owns" the prefix. Why have any ownership at all? Because you need an
authority to assign semantics. True, such semantics may not be universal;
they may be ambigous outside of local processing context. But the registry
would not care: it does not maintain semantics-- it establishes the
semanitic authority for the short-sequence namespace id, but no information
about what the prefix "means" appears there.
I can understand the desire to do something more, to make a powerhouse of a
registry will full blown name enumeration, definitions, and who-knows-what.
I'm daring to suggest less. In true Doublespeak fashion, sometimes less is