RE: FPIs to URNs

lee@sq.com wrote:

>Ken Holman was confused by my example -- which wasn't clear to those who
>have not followed URNs at all, I agree.  Sorry.  He said:

And some of us who have followed URNs, as Mitra was a vocal advocate
of the (incorrect) viewpoint that DNS should be a required part of the URN
infrastructure -- and so the name you chose was suggestive to some...

>If it is easier to understand, imagine, if you will, that I am asking
>for a slightly different syntax for FPIs, with a hierarchy of organisations
>who can allocate naming authority prefixes.
>	+//NA:US:CA:SUN:SUNSOFT:DIVDOC//DTD XXX YYY//EN
>for example.

This is already part of the FPI syntax (except that they use :: instead
of : to assign subauthorities). It is also problematic to base resolution on
naming authority in the long run -- as names are supposed to persist, but
the control of a name may change over time: There's a URN problem
that is equivalent to the URL hell cause by the move from CERN to W3C.

So we have the infrastructure you ask for in FPIs already.

>This would be easier to arrange for automatic resolution, easier
>to administer and more robust.  Or so it seems to me.
well, robust over a 5-10 year period anyway.

>Ignoring the misunderstanding about the domain name....
>This is a real issue.  A lookaside cache can be called CATALOG if it
>makes people happy, but that is all it is; you can have a cache for
anything.

If I can hand-edit it (maybe with a nice tool, of course) then it's more
than
a simple cache, which is restricted to monitoring what's happening. As an
aside,
we should consider a way to label an XML entitiy with its FPI: This would be
a
one-sentence change in the standard if we were using something extensible
like HTTP headers, rather than processing instructions. This way we can
_have_
a cache, if we want.

>> >This is my biggest concern with the (literally) millions of
>> >unregistered
>> >public identifiers belonging to tens of thousands or hundreds of
>> >thousands or more of issuing "authorities".
>> 
>> Good reasons for me to not include the resolution aspects of any kind of
>> identifier in the XML specification.
>
>If we don't believe they will work, WE MUST NOT RELY ON THEM, and
>cannot use them in the spec.  Period.  No hand waving.  No ``we left
>that out of the spec hoping no-one would notice our whole plan was
>built on a false premise' :-)

This is the URN problem, and as has been said over and over: if you have
a name, and the SYSTEM ID is broken, there is no way in hell you will _ever_
be able to guarantee that the name can be resolved. However, if you have a
broken SYSTEM ID, you can look to the name for help, and if you have a
broken
name, you can look to the SYSTEM ID for help. This is redundancy in the
reliable-
system sense (good), not the authorial sense (bad).

>If it is easier to understand, imagine, if you will, that I am asking
>for a slightly different syntax for FPIs, with a hierarchy of organisations
>who can allocate naming authority prefixes.
>	+//NA:US:CA:SUN:SUNSOFT//DTD XXX//EN
>for example.

Since FPIs already have this, maybe we need a real objection. And please
remember that guaranteed resolution is impossible for any kind of name,
which does _NOT_ make names useless.

The reason I am now backing PUBLIC as opposed to URNs in SYSTEM
is that the fallback strategy I outlined is not possible if we have a
single ID that is only a URN, and no URL. You may think of the URL
as a kind of "hint" but it lets people use names (and SGML tools) now,
while still be compatible with the future. And if URNs eventually take
off, the PUBLIC ID may become a quaint relic -- but if it takes a while
they will be useful.

  -- David

Received on Thursday, 5 December 1996 12:35:52 UTC