[
Lists Home |
Date Index |
Thread Index
]
> "Instauring a registry is a perfect way to prepare a robbery onto the
> enslaved masses. Prepare your checks ! Even if someone promises you
> whatever freedom now, the capitalist temptation of making money on
> any central authority is just impossible to resist in the long term."
>
> A technical solution based on a registry is by essence centralized,
> prone to failure, gives a terrible control to whoever maintain them,
> and basically cripples the technical framework you're trying to build
> with them.
But we have such registries everywhere. Obviously they are not pure evil,
but they do have some tradeoffs.
> When the data are very static and nearly never
> change it ain't too bad,
Good! One minor point of agreement.
> but for things like binding of public and internal identifier
> it's a terrible solution, then people start to fight over names and
> control of that mechanism.
One thing that I haven't made clear is that the registered prefix is, in all
essence, the namespace identifier. URI's become mere resource pointers,
which is what they started out as being anyway. Gee, no dual-purposing of an
identifier... what a concept!
> DNS is a prime example, but google ranking,
> realnames, trademarks, domain names, Mime-Types, etc are
> other examples
> where keeping or maintaining fair association of names and
> identifiers/
> semantic have proven to be a pain.
But if they're so painful, why are they there? Could it be that "no pain,
no gain"?
[snip]
> Now to get back to the initial proposal building a registry for
> XML namespace prefixes seems impractical (one would have to modify
> all the parsers ... after having changed the semantic of the specs),
No, let's not modify parsers, at least not yet. First of all, I'm not
proposing to toss out the existing namespace mechanisms, but merely
suggesting that such namespaces prefixing be labelled 'provisional'. Leave
those as they are.
The problem that makes it difficult for a registered and a provisional
prefixing scheme to coexist in the same document is that the Namespaces for
XML proposal has locked up one of the few good delimiters for separating
prefix from local name. Worse, it doesn't allow telescoping of prefixes, so
that one can't do something like
<msft:soap:lather>
foo!
</msft:soap:lather>
which is wordy, but would be a useful mechanism for prefix contention in a
registry.
I think what's left is to use a period as a registered prefix delimiter.
Telescoping (I'm probably abusing a term, sorry) of registered prefixes is
something to think about, but the pain/gain ratio may not be sufficiently
close to 80/20.
> this would break a lot of namespace based specs which expect scoping
> this won't solve some of the hard problems which occurs when mixing
> namespaces in document,
I think it does, since many of the problems with mixed document namespaces
can be traced to default namespace declarations, IMVHO.
> this won't solve problems related to dynamic
> generation of prefixes (like in XSLT),
If the prefix is always attached to a name, wouldn't it help? I don't have
my XSLT book handy so I can't refer to examples. Maybe someone who uses it
more could offer one.
> but this will create the market
> for another ICANN monster, where I bet all the single letter prefixes
> would suddenly become quite expensive ...
Let me answer that in the next post.
>
> Insane, really ...
>
> Daniel
>
> --
> Daniel Veillard | Red Hat Network https://rhn.redhat.com/
> veillard@redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
