Re: ERB discussion of public identifiers

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

> 3. Put a slot in the syntax for PUBLIC identifiers...
>   3* ...and require an accompanying SYSTEM identifier
If you don't specify a resolution mechanism, the SYSTEM identifier will
certainly be required.

>   3a - say nothing about resolution mechanisms, perhaps providing a
>        taxonomy of available technologies in this area
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.... :-)
If you expect programmers to write code, the functionality of that code
must be in the spec.  There isn't anywhere else for it, unless you can
include a normative reference to another text (e.g. to the X500
specification for ISO directory services, which obviously (?) should be
preferred in an ISO/SGML context over the IETF URN work :-)

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

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.

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

I would still favour omitting PUBLIC for XML 1.0.

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.

Allowing PUBLIC "xxx" to be ignored in XML has (as I see it) only a single
advantage -- it is then possible to have an XML file that is also a legal
HTML file, as long as it doesn't use any EMPTY elements or entities.
It doesn't help you use existing SGML tools on your XML, as unmodified
SGML tools don't actually work with XML (they don't interpret the charset
processing instruction, for example, and have problems with the NET tag).
Yuo have to modify your SGML files to use them with XML, althouth the
transformatioon is automatic and simple.
That modification can remove PUBLIC.
You have to modify XML files to use them with old SGML tools.
That modification can add PUBLIC.


Lee

Received on Wednesday, 11 December 1996 17:42:59 UTC