Re: ERB discussion of public identifiers
At 5:40 PM 12/11/96, email@example.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")
I am not a number. I am an undefined character.
David Durand firstname.lastname@example.org \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________