Re: ERB discussion of public identifiers

At 12:05 PM 12/11/96, Tim Bray wrote:
>We spent a lot of time on this question on Dec. 11th, and it is clear we
>need some more help from the WG.
>
>The ERB is, by at least a substantial majority, convinced that there is a
>real nead for PUBLIC identifiers in XML.

yay!

>The ERB is highly concerned, in at least a significant minority, about
>the effects of putting this facility in without specifying a resolution
>mechanism.  Doing so would contravene one of the major design goals of
>XML - that any compliant XML processor should be able to read any compliant
>XML document.

They'll get over it. "Mechanism independent" means that a requirement of a
specific mechanism is not productive. We _should_ suggest URNs and SOCAT as
possibilities and leave it to the market.

2 key points:
   1. PUBLIC IDs, if resolvable by a parser, should take precedence over a
SYSTEM ID. This lets people who want to count on naming do so...
   2. SYSTEM IDs must be required. This means that there is always _one_
resolution mechanism that can be tried even if you do nothing with names.
People with internal use of PUBLIC and active opposition to SYSTEM can just
put in an empty string.

>On the other hand, there is also substantial concern about giving an
>unconditional blessing to any particular name resolution mechanism at
>this point in history.

Given the state of implementation and acceptance it would be foolish.

>Thus, there are a variety of options open to us.
>
>1. Leave it as it is

Please, no!

>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.

Since a mandatory resolution mechanism is an anti-requirement, I think this
is a bad approach.

>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.
3b* please:
   We suggest the two most likely, allowing for doing nothing, and require
a SYSTEM ID for those who find it disturbing not being able to tell if you
can resolve a name or not.

  [ Note that this is the real difference between URL and URN resolution:
you can tell that a URL is broken at time T, by trying to fetch the
resource and seeing if you get it. Given a URN, you can _never_ tell if it
is really broken, or you are just trying to wrong mechanism to resolve the
URN. ]

>   3c - document one resolution mechanism as before, but make its use
>        mandatory for XML processors.
>
> Note that there is a continuum between 3b and 3c; we could place
> varying strengths of recommendation behind one resolution mechanism,
> with homilies about document portability.\

I think 3c is actively unhelpful, as it removed one of the key kinds of
flexibility that make URNs/FPIs attractive to those who find them
attractive.

>In the area of which resolution mechanism to (perhaps nonexclusively)
>bless, SGML/Open catalogs (hereinafter Socats) stand out, and would
>probably be the ERB's choice.  On another hand, there has been a lot
>of work go into the URN effort; on another hand, that work has not yet
>born practical fruit in terms of ubiquitous implementations; on another
>hand, the FPI syntax is repellent to some and it is not clear how well
>it supports internationalization; on another hand, it may be the case
>that FPI's really are URN's as they stand.
FPIs probably will become URNs, with some kind of prefix. URN syntax is
already divergent from FPI syntax (and in the initial characters, too).
Maybe we shoul follow Keith Corbett's excellent suggestions:
   + FORMAL NO
   + URN, FPI both legal (I would add 9070 Object identifiers too, but I'm
a weirdo).

Keith's comment sums it up nicely:
> The message to Web publishers is very positive: XML supports a useful
> feature for interchange with name resolution systems, and XML will scale
> better than HTML as industrial strength naming schemes come online.

Tim, again:
>I suspect that if a binding vote were taken today, the ERB would either
>(a) reinstate the PUBLIC keyword, and put in a nonexclusive recommendation
>    for Socat support, or

Acceptable.

>(b) refuse to put PUBLIC in until there was agreement on a required
>    resolution mechanism.

Wrong, because it eliminates one of the reasons to _use_ PUBLIC.

>Input, please.

more than you want, I'm sure. You're welcome.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Thursday, 12 December 1996 12:52:27 UTC