Re: the return of the Public Identifier Question

Michael Sperberg-McQueen writes:
[citing Terry]
>>XML should be okay, too.  Catalogues are not resolution mechanisms,
>>they are indirection mechanisms, and that's just right.
>
>I'll have to reread the SGML Open spec in its current incarnation,
>but the last time I looked I thought the rhs of a PUBLIC entry
>had to be a system identifier.

We are treating the rhs as including a URL, are we not? Only a
URL, or is a filename (implicitly a local filename) also possible?

>>|   a Support for full SGML Open catalogs ...
>>|   b ... a suitable simplification of SGML Open catalogs ...
>>
>>Either way you get indirection, not resolution.  

You get resolution if the rhs is a URL (assuming that it's valid
and the network is connected).

>idea again.  As I understand it, either (a) or (b) would naturally
>be coupled with information about where to find the catalogs, and
>with some constraints that would ultimately, for any public identifier,
>either produce a system identifier or fail.  I think of producing a
>system identifier for a resource accessible to the processor as
>constituting resolution of the public identifier; am I misusing the
>term?

No, so long as a sysid is a URL. There is a danger, which you both
clearly recognize, of catalogs being seen as the resolution mechanism.
Just producing an unspecified format of system identifier as the outcome 
of the use of a catalog is insufficient: resolution must mean "identifying, 
locating, and retrieving the {dtd|charentfile|dtdfrag} represented by the 
{fpi|url|sysid}". 

>>But in the current environment of push for solutions to simple problems,
>>I would much rather that XML cut loose of this issue.  On the Internet,
>>the SGML notions of PUBLIC and SYSTEM aren't too useful, and eliminating
>>both in favor of URLs is a win (whatever the metaphysics of URLs).  If
>>I want to use URNs, nothing in XML 1.0 prevents me.

I'm sure lots of people will do this, but in the long term I'd prefer
the durability of the extra indirection of an FPI, not to mention the
inherent factors of ownership/authorship, classing, and language. 
Reliance solely on URLs for ever will make your hair fall out and your 
teeth rot (how many non-existent links are there in your average daily
search request to a popular indexing engine? :-)  

What I want is a peered server system something like a combo of LISTSERV
and DNS, so I can query any server for resolution of an FPI, and if it
doesn't have it, it will pass me to somewhere that does, and ultimately
(here's the rub) to the home site of the Public Owner, who should be
_required_ to resolve it. Unattainable? Perhaps right now, maybe one day.

In the meantime, URLs or a voluntary resolution service will have to do.
DTDs and char ent files are not that big in the global scale of things,
even when they are "large" systems like the TEI. I'm happy to give over
a few Mb of space to them, and to service requests for FPIs for the 
moment. We just need to make sure we don't preclude a scalable solution.

///Peter

Received on Thursday, 20 March 1997 18:44:01 UTC