Re: the return of the Public Identifier Question

Michael writes lucidly:

| Executive summary:  ERB will take up the question of public identifiers
| next week.  Current leaning appears to be toward
|   - including syntax for public ids
|   - defining a resolution mechanism which all conforming XML applications
|     must support (non-exclusively) -- if not in the next draft, then in
|     a future revision

My executive response, detailed below:  please don't.

|   - not specifying the order in which applications should try
|     the public and the system ids, but requiring that if the first one
|     fails, the other one should be tried.
| 
| -----------------------------------------------------------------------
| 
| During its meeting today (19 March 1997), the ERB discussed (among other
| things) the preparation of a corrected draft of the XML language spec in
| time for distribution at the Web conference next month.

This spec constrains processors/parser, posits applications, but
in its current version makes no requirements on apps (have I missed
something?)  BTW, these are not rhetorical questions I ask; I really
do expect responses, particularly from SGML ERB members.  Response
to public comment builds credibility and legitimacy.

| In particular, we agreed to vote, next week, on the issue of public
| identifiers and their inclusion in the XML-Lang spec.  This issue was
| discussed in the WG when the subcommittee draft was released on 31
| January, but without reaching an absolutely clear consensus.  The ERB
| discussion (and an informal straw poll) made fairly clear that the ERB
| is leaning to the position(s) described below.  Those with an interest
| in this topic have a week to confirm the ERB in its leanings, or make a
| conclusive case for another solution.  (Simple reiterations of arguments
| already made do not, however, qualify as a conclusive case.)
| 
| 1 There is strong but not unanimous sentiment for changing the syntax of
| external identifiers in XML to allow public identifiers.  Some on the ERB
| would strongly prefer that a resolution mechanism be specified as well,
| but at least some of the pro-resolution camp are willing to add the
| syntax even if no consensus can be reached on a resolution method.
| 
| 2 There is also a general leaning toward the view that if public
| identifiers are included, a resolution mechanism should also be defined.
| (Pro:  an implementer can read the spec and know what is involved in
| supporting it.  Con:  there is no currently accessible resolution
| mechanism that appears to command consensus, so there is nothing ready
| for inclusion in the XML language spec.)

It is not clear here whether the specified resolution mechanism
is a fallback or must be applied first.   Paul has suggested that
not saying is the best policy; that's okay by me, but the XML spec 
must say what is conformant behavior.

| If we can agree on a suitable resolution mechanism, we'll include it
| in the revised spec (see below for an explanation of why this seems
| unlikely); if we can't, we'll include the syntax in the spec anyway,
| with a note that work on a resolution method is continuing.
| 
| 3 There appear to be three approaches to resolution that command
| or could command non-negligible support:
| 
|   a SGML Open Catalogs, as specified in the current version of the
|     relevant SGML Open technical resolution

If a catalogue can give as the rhs another public identifier, this
choice does not really result in specifying a resolution mechanism;
and if that's okay, then punting to mechanisms entirely outside
XML should be okay, too.  Catalogues are not resolution mechanisms,
they are indirection mechanisms, and that's just right.

|   b a simplified form of SGML Open Catalogs, not necessarily that
|     proposed on 31 January by the subcommittee
|   c reliance on URN resolution mechanisms

which is like reliance on electricity.  I was all set to write
some email yesterday morning when two monstrous PG&E trucks
pulled up with half a dozen guys to take out my electricity for
a hour to fix some downhill transformer.  The day was clear and
calm, no idiots had hit power poles, but I still lost power.

My point is that resolution (having power working) is not 
indirection (choosing among PG&E, windmills, solar power, etc.),
and that any choice of method may result in failure of resolution.

YMMV.

| With regard to these, the ERB leanings appear to be:
| 
|   a Support for full SGML Open catalogs is probably more work than
|     should be demanded of XML implementors; the relevant TR should
|     probably be mentioned as a relevant standard, but not incorporated
|     in full.
|   b The ERB is leaning toward including a suitable simplification of
|     SGML Open catalogs in the XML-Lang spec as a required
|     minimum for XML implementations.  

Either way you get indirection, not resolution.  If that's okay,
it needs to be said what this requirement means for the processor/parser,
the application (a term not used since the executive summary), or
the implementation (=application?).  I nag at this point because
the concept of an XML application is currently a loose cannon.

| Conforming implementations may
|     support additional resolution techniques as well, but should all
|     support at least this one.  However, there is no consensus that
|     the current subcommittee draft hits the right note here, and it
|     seems likely that the draft of 31 March (or whenever) will have
|     just a promissory note.
|
|   c URNs will be a plausible mechanism to consider when they are
|     complete, but this appears not yet to be the case.

As for specification, the URN I-Ds are in last call.  That's about as
complete as they'll get.  

As for resolution mechanisms, I'll point out that you can serve resolution 
information for URNs along with the docs that contain the URNs, solving the 
resolution problem for the short term if only the user agent has 
a means of caching URN resolution information.

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.

More generally, resolution of indirect names is not unique to XML
and ought to be dealt with on a system-wide basis, just like resolution
of URLs.


Regards, 
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
       specializing in Web publishing, SGML, and the DocBook DTD 
                   http://www.sonic.net/~tallen/
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Thursday, 20 March 1997 00:51:27 UTC