Re: URL better than FPI

Arjun Ray wrote:
> 
> On Fri, 18 Feb 2000, Russell Steven Shawn O'Connor wrote:
[...]

> > Why is it a problem?  Why should PUBLIC identifiers be used over
> > SYSTEM identifiers. ... Um, can you define the semantics of PUBLIC
> > and SYSTEM identifiers?  Don't bother if it is too much trouble.
> 
> In terms of the great Undead Debate - Names vs Addresses - PUBLIC is
> basically a "name" and SYSTEM is basically an "address".  There's also
> an understanding that PUBLIC is portable across environments whereas
> SYSTEM is always necessarily "local", that PUBLIC ids are effectively
> permanent while SYSTEM ids normally *do* vary, and so on.

Ah! So you're saying PUBLIC/SYSTEM expresses a *relationship* between
identifiers, rather than independent characteristics of the
identifiers themselves? If so, I don't disagree with you after all.

The only issue is the constraints on the syntax of what goes
inside PUBLIC "..." vs. the unconstrained SYSTEM "..." syntax.
I completely agree that we only need one and that it's awkward
that XML 1.0 picked the SYSTEM "..." as the required slot,
but (if I understand correctly) that was the only slot where
URIs fit, and I'd rather have a misnomer in the syntax than trade in
the benefits of the widely deployed Uniform Identifier syntax.

[...]

> So, it's not PUBLIC ids but SYSTEM ids that are the real "baggage".
> Unfortunately, we're also stuck with the formal variant of PUBLIC ids
> (FPIs), which has been a big problem until the WebSGML TC offered an
> extension for networks (the +//IDN registered owner class), which now
> gives us a way to stick the informational content of a URL into a FPI.
> A win/win:)

Hmm... well... it doesn't seem that the "+//IDN ..." syntax accomodates
URIs that aren't DNS-based; e.g. uuid:23io423oi423oi4
or oid:12.424.54.34.23.23.45.24 or even mid:l2k3j42lkj3@foo.com
or tel:+1-444-555-1212 or futurescheme:whatever-goes-here .

The "http:" in "http://www.w3.org/" serves not only as a clue
to what network protocol to try, but also to dispatch between
completely orthogonal naming schemes.

In a way, the registry of URI schemes (http:, ftp:, ...) is
analagous to the registry of registered owner identifiers (+//xyz).

[...]

> In that what we *need* is to put the URL into a PUBLIC id, i.e. that
> the literal that follows the PUBLIC keyword should be a URL, or its
> informational equivalent.  There is absolutely no reason why we should
> not be able to do this.

In theory, I agree. Hmm... in practice, I wonder if it would
be easier to get ISO to relax the syntactic constraings on PUBLIC
identifiers than to deploy a convention of mapping +//IDN foo.org/...
to http://foo.org/... or ftp://foo.org/... or whatever.

Probably ISO isn't the rate-limiting-factor; probably, the
consequences of putting PUBLIC "http://..." into deployed
SGML systems is the deployment constraint. But I haven't done
much testing.

-- 
Dan Connolly
http://www.w3.org/People/Connolly/

Received on Saturday, 19 February 2000 01:00:30 UTC