re ERB discussion of public identifiers

I fear all the discussion about FPIs as URNs has sailed right over
many heads.  Tim Bray writes:

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

Understanding a name ("reading" it) is different from being able to 
resolve it and obtain the object it names.  If the design goal is
really that all reference must always work, be they SYSTEM or 
PUBLIC, you'll have to discard it anyway.

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

If name resolution lies outside the scope of the XML spec, as I think
it ought, then no particular mechanism at all should even be mentioned.

Your choice seems to lie between treating PUBLIC IDs as URNs, which means
"hand it off to your URN resolver"; defining a mechanism for resolving
some larger class of vaguely "public" identifiers peculiar to XML;
and defining some particular way to resolve FPIs for the Internet.  The 
last course would preclude using URNs that aren't FPIs, which is not 
a very appealing or sensible course.

If the decision is "hand it off to your URN resolver," then no
resolution mechanism need be recommended or required; URNs are
names, you will resolve by whatever means suit you best.  

| Thus, there are a variety of options open to us.

Not those you list (see above).  The ERB's in a pretty deep hole on 
this one, having deleted from SGML an essential capacity for indirection.  

| 1. Leave it as it is

And appear hidebound, ignoring the example of peer specs
such as VRML, the existence of IETF activity on URNs, and
the utility of indirection.  Will that appeal to your target
audiences?  will that persuade the great unparsed public
that SGML experts have a clue and that their XML spec can
be regarded seriously?

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

Equivalent to 1.

| 3. Put a slot in the syntax for PUBLIC identifiers...
|    3* ...and require an accompanying SYSTEM identifier

Why require?  Just say that the author has the two choices of
how to refer, by URL (SYSTEM) or URN (PUBLIC), or both.  If
you like, point out that URN resolvers are no more widely deployed
than user agents that read XML, and *recommend* use of a SYSTEM
identifier if the author isn't confident that the PUBLIC ID 
will be resolved by his target audience.  To the extent it
doesn't work right now, people won't use it exclusively.
 
|    3a - say nothing about resolution mechanisms, perhaps providing a
|         taxonomy of available technologies in this area

Bingo.  If you define PUBLIC IDs as URNs, resolution mechanisms are
entirely out of scope.  Which is a big win for the size and
simplicity of the XML spec and of XML applications.  But I think
you must say that PUBLIC IDs are to be resolved as URNs to grasp
the laurels.

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

That is, add unnecessary verbiage.  Your i18n approach is not a
good parallel; it does make requirements on user agents.

|    3c - document one resolution mechanism as before, but make its use
|         mandatory for XML processors.

Meaningless if PUBLIC IDs are URNs.

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

Not really.  So far as implementation conformance is concerned, there is 
only SHOULD and MUST.  Jawboning counts for nothing in the Internet
standards game.

| 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

Are you really willing to rest XML on the admittedly incomplete 
("80% solution") and increasingly crufty (viz. the well-meaning proposals 
at the technical committee meeting in Boston to add more and more 
facilities to it) socat approach -- necessary as it may be off the
Net -- instead of relying on independent Internet name resolution services
and relieving yourselves of the necessity to deal with name resolution 
entirely?

| 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

This is as bogus as Lee's "URNs aren't ready yet".  The URN work, while
as undeployed as XML, is farther advanced, and XML isn't due to be finished 
for a year.  I am unaware of any XML implementation that is even biquitous, 
much less ubiquitous.  You are writing the XML spec in an environment
of very rapid development, and you want to be able to sell it to
people who work in that environment.  

Yesterday's URN session at IETF was eerily harmonious, especially for
that group, *as if people understood that they were close to acheiving
something they all think is extremely valuable and which they want to 
use as soon as possible*.  The syntax draft is very nearly complete 
(it doesn't have whitespace problems).  That's really about all that's 
necessary for people to start constructing resolution systems (beyond 
the current deployed demonstration of a scalable resolution mechanism).  
Nobody is worried that URNs won't work.

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

Literally, no, there is a distinction between the name in its native
name space and that name as encoded as part of a URN.  E.g., spaces must be
hex encoded (%20).  They can be converted to URNs and resolved as such.
The ERB must specify whether PUBLIC is to contain an FPI or a URN, e.g.,

   urn:fpi:-//Davenport//DTD%20DocBook%V3.0//EN

(I've forgotten whether the slashes must be escaped also.)

| 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
| (b) refuse to put PUBLIC in until there was agreement on a required
|     resolution mechanism.

which is to say, maybe never?  



Regards,

    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Friday, 13 December 1996 21:09:38 UTC