Re: ERB discussion of public identifiers

At 5:40 PM 12/11/96, lee@sq.com wrote:
>> 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.
>
>I think this is sensible.

Since there will _never_ be a single resolution mechanism, this is not sensible.

>I think this is a cop-out:
>"XML has a feature which is not documented in the spec, but
> here is the telephone number of the ERB members so you can ask
> how to implement XML properly" reminds me of another markup
>definition language.... :-)

This straw man has been burned repeatedly.

>There is no use (as far as I can see) for PUBLIC "string" being in the
>XML spec if XML systems all ignore it.  It just clutters the language
>(like the - - omissible tag parameters, or "<!DOCTYPE X SYSTEM>").

But we have seen that not _all_ systems will ignore it. Just the ones that
you write, I guess. That's OK.

>A restricted subset of CATALOG, together with a documented set of
>mechanisms for resolving the catalog itself, might work.  The mechanism
>for finding a remote catalog over ftp or http must work in the presence
>of CGI scripts and URLs with / in a query.
>
>I can post details of what SoftQuad Panorama does if it will help.
>It can all be described in under a page, I think, taking us to 28pp,
>although we're still some 50% over the 20 page goal.
>
>
>>   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.
>
>The difficulty with this is that URNs aren't ready yet, and SOcats only
>defer the problem: you then have to say how to get the catalog.
>On the other hand, we are going to have the same problem with
>associating style sheets with documents, and with following hypertext
>links based on public identifiers for documents.

CATALOG has default places to look that extend trivially to URLs and
relative URLs -- this is another straw man. It is common to defer complex
mechanisms one needs to protocols that provide those mechanisms -- And
commonplace for schedules to be less-than perfectly aligned in such
development. More straw.

>>   3c - document one resolution mechanism as before, but make its use
>>        mandatory for XML processors.
>I don't think this will fly, ,as we don't have a single mechanism that
>satisfies everyone's needs yet, I think.

There is no _single_ mechanism that can meet the need to have multiple
mechanisms. This point has been rather frequently repeated.

>The concerns that have been voiced all seem to relate to using SGML in
>an SGML context; it's not clear to me that the same concerns and
>implementation constraints apply to XML.  There has been no clear statement
>in support of PUBLIC saying what functionality is needed and why.

I can repeat my quote from the URN list yet again, but I will let you look
it up: (Hint: it's short and starts with  "Mechanism independent")

  -- 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:26 UTC