Re: ERB discussion of public identifiers

> From: Tim Bray <tbray@textuality.com>
> 
> Thus, there are a variety of options open to us.
> 
> 1. Leave it as it is
> 
> 2. Agree that we'll put PUBLIC identifiers into XML *when* we are ready
>    to specify the resolution mechanism; the practical effect is almost
>    certainly that they don't go in for now.
> 
> 3. Put a slot in the syntax for PUBLIC identifiers...
>    3* ...and require an accompanying SYSTEM identifier
> 
>    3a - say nothing about resolution mechanisms, perhaps providing a
>         taxonomy of available technologies in this area
>    3b - document one resolution mechanism, but not make it required.  
>         This is somewhat similar to our i18n approach, where we bless 2 
>         encodings but admit the possibility that people use others.
>    3c - document one resolution mechanism as before, but make its use
>         mandatory for XML processors.


Even though I was editor of the SGML Open "catalog" Resolution, I have
read all the email and considered all the options.  

I do want public ids and the indirection they give.  That means there
has to be some resolution mechanism (not that it has to be in the XML
spec or there is only one, but merely that resolution will be a
necessary step when using public ids).

Since SGML Open catalogs have been accepted, implemented, and used as 
one resolution mechanism, it is important to me to be able to continue
to use them to resolve XML public ids.  Since I can see benefit in
allowing other resolution mechanisms, I am led to choices 3a or 3b.

In the interest of having interoperable tools, I lean toward 3b.  In
fact, I would support having the XML spec require support for some
(possibly simplified as per Ken Holman's posting) catalog resolution.
Almost all the postings I have seen against mandating a resolution
mechanism give good reasons why users/authors/tools shouldn't be restricted
to a single resolution mechanism, but I have not seen arguments (except
the "it's too hard to implement" argument that I have not quite accepted)
to suggest that there is a downside to requiring XML tools to support
catalog resolution.  What I'm saying differs from 3c in that the use
of catalogs would not be mandatory, but *if* the user/author wants to
use catalogs, support for its use would be mandatory for all XML tools.

Finally, I'd be happier with any of the 3-ish choices than not having
public ids in XML 1.0.


> From: Peter Flynn <pflynn@curia.ucc.ie>
> 
>    3. Put a slot in the syntax for PUBLIC identifiers...
>       3* ...and require an accompanying SYSTEM identifier
> 
> As a list newcomer, I wasn't party to the previous debate on this, but
> whichever way it goes, I feel it is essential to specify what the
> order of acceptance is. The current position in SGML is a serious
> problem for users and implementors, where one application will use the
> SYSTEM identifier if it is there, and ignore the PUBLIC identifier
> even if it cannot locate the resource referred to by the SYSTEM
> identifier; and another application takes the PUBLIC identifer first
> and ignores the SYSTEM identifer even if it cannot resolve the PUBLIC
> identifier; and yet others work only with PUBLIC identifers or SYSTEM
> identifers but not both.


I would not want XML to require a SYSTEM identifier.  I also wouldn't
want it to require a PUBLIC id.  I'd like to leave it as it is now in
8879 in that respect.  This gives maximum flexibility to the user.

As far as precedence of the PUBLIC versus SYSTEM id when both are given,
the SGML Open technical committee had long discussions on this topic
in 1993 and 94 when drafting TR9401.  Some SGML luminaries argued that
it was obvious that the SYSTEM id should always be preferred while others
argued that certainly the PUBLIC id should always be preferred.  After
much heated discussion, if nothing else was clear it was that neither
position is obvious.  TR9401 decided to say that all implementations
must support the user's ability to say whether they wanted to prefer the
PUBLIC or SYSTEM id.  In fact, the same user may wish at one time to give
preference to the PUBLIC ids and at another time to give preference to the
SYSTEM ids.  

Provided that all catalog implementations comply with the requirement to 
give the user this choice, I see no problem.  

(Peter, perhaps you can tell me more off-line about:
  The current position in SGML is a serious
  problem for users and implementors, where one application will use the
  SYSTEM identifier if it is there, and ignore the PUBLIC identifier
  even if it cannot locate the resource referred to by the SYSTEM
  identifier; and another application takes the PUBLIC identifer first
  and ignores the SYSTEM identifer even if it cannot resolve the PUBLIC
  identifier; and yet others work only with PUBLIC identifers or SYSTEM
  identifers but not both.
It sounds to me like you must be looking at non-compliant implementations.)

paul

Received on Sunday, 15 December 1996 15:22:17 UTC