Public Identifiers

Wow, for the first time in this process I went away for a week, now I feel
the pain of anyone who cares about this but gets a little behind.  Anyhow,
a flight from Sydney to LA makes an excellent venue for catching up on this
stuff.

Anyhow, having slogged through all this, I think that a powerful case
has been made that since people are using public identifiers, we shouldn't
get in the way of so doing in XML documents.

The discussion has also made it clear that it would be a huge mistake to
wire in a requirement for processing FPI's or URN's or for an understanding
of the kozmic chasm between the buddha-natures of Name and Location.

Adopting Ken's proposed syntax delta seems like the way to go, minus the
explicit references to catalog grammars (we shouldn't overlap with other
specs, particularly when they're moving targets) - it also seems sound to
point out that there are these things called FPI's and ISBN's and URN's and 
URI's and FSI's and Socats (love that) and that the implementor should bone 
up on them before implementing a public identifier resolver.

I share Michael's discomfort at specifying a reference capability
without including the resolution mechanism, but it is an undeniable
fact that [a] people *are* using public identifiers usefully, and
[b] there is nothing remotely approaching consensus on how to
go about naming and locating things.  So to address Michael's
concerns, I'd say that the only way that you as an information
provider can really control which versions of components get addressed is 
to use an absolute URL pointing back a machine you operate.  But, just
because *we* don't all agree on how to achieve permanence, portability,
and guaranteed uniqueness in a naming scheme, doesn't mean we shouldn't
let people use names.

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-488-1167

Received on Monday, 9 December 1996 09:36:57 UTC