Re: Client-side-resolved Indirection

On Mon, 2 Dec 1996 10:33:02 -0500 Paul Prescod said:
>>Certainly the SGML Open scheme has its benefits and features, but I
>>agreed with Debbie that the minimum is a simple string comparison.
>>If I choose to go beyond that with an SGML Open catalog, I can
>>choose to do so without impacting on my marked up source.
>
>Could you clarify here? Do you and Debbie wans a simple established
>mechanism for name resolution, or just the option to put in the public
>identifier (which is what I have been pushing for).

I'm not sure I have understood you both correctly -- if I have, you
are arguing in favor of adding PUBLIC identifiers without specifying
how they are to be resolved.  I can't believe my eyes.

True, adding the syntax without describing the semantics would only add
a few lines to the specification.  It seems to me, however, that it
would blow XML out of the water and more or less completely eliminate
the chances that independent implementations would inter-operate except
by accident.

>>Then again, need XML establish the "environment" in which XML PUBLIC
>>identifers are dereferenced?  Is it in the scope of XML to go outside
>>the syntax of the markup to specify any obligatory mechanism by which
>>information in the markup is handled?
>
>Well, URLs must be handled according to URL semantics so we *could*
>specify a resolution semantic for public identifers. But I think
>that would put an extra burden on implementors, risk XML's
>acceptance, and inappropriately disqualify the URN effort before it
>got off of the ground.

I think this boils down to having a paragraph in the spec which says
(possibly in different words) "PUBLIC identifiers are magic cookies,
which are resolved using a Magic Cookie Resolution Algorithm which lies
outside the scope of this specification.  As a consequence, no two XML
processors are likely to resolve them in the same way; implementors are
encouraged to distinguish their processors by the ingenuity of their
resolution methods, using SGML Open catalogs, clever directory path
tricks, ad hoc configuration files, magic flashing lights and sirens, or
other mechanisms."

Does that make anyone really want to use this system?  Not me.

We tried that approach once before, in 8879.  It left all the details
open to the implementors.  The implementors exercised this freedom for a
while, but ultimately chose (driven by their users? or by the odd desire
to make 8879 live up to its billing?) to abandon it and specify what
8879 left unspecified.  Now we have the SGML Open catalog, and PUBLIC
identifiers work.

To answer the question someone posed:  No, I, for one, did not use SGML
public identifiers before the advent of the SGML Open catalogue, because
no two systems I had resolved them in the same way; with system
identifiers, at least, my troubles were limited to the times when I
moved documents from one system to another.  With public identifiers and
no common resolution mechanism, I saw no payback at all for the effort
of learning a different ad hoc odd hack solution for each parser, and
strewing copies of my DTDs all over my hard disk.  Not all operating
systems have symbolic links ...

I think FPIs are a Good Thing, and I'd like to see them in XML.  Like
Tim and some others, I went into this process assuming FPIs and SGML
Open catalogs would clearly be part of the spec.  But FPIs are, I think,
not Absolutely Essential, since I know from experience that one can work
a long time with only SYSTEM identifiers.  Maybe they don't belong in
XML 1.0; get something out quickly that's easy to implement, and which
can easily be seen to be easy to implement.  Maybe they do; I'm agnostic
on that point.   But one thing seems clear to me:  if we have them, we
need to specify how to handle them.  If we don't, we are giving up
without reason on the goal of interoperability and complete explicit
definition of the language.

Or am I wrong?

Michael Sperberg-McQueen

Received on Monday, 2 December 1996 11:17:45 UTC