Re: the return of the Public Identifier Question
Christopher R. Maden <firstname.lastname@example.org> wrote:
> Liam Quin <email@example.com> wrote:
>> The SGML "promise", as I understand it, is that the result of fetching
>> an entity referred to by a Public Identifier will be the same today,
>> tomorrow and always, here and in Madagascar and on the Moon.
> Not true - see clause 10.2.2.5. That clause only applies to "public
> text for which a _public text display version_ () could have been
> specified but was not" (despite the fact that "if the public text is
> device-dependent, the text identifier must include a _public text
> display version_ ()").
But see the SGML Handbook's gloss on thison page 389 for a different view.
> The important precedent here is that the same *logical* text is fetched.
Well, the same Definitional Text must be fetched. I.e. the same byte
stream, except for "coding that is system or device dependent" (e.g.
ASCII vs. EBCDIC).
I don't really want to argue about this when the real issue is elsewhere:
what will *XML* mean by a public identifier.
Incompatible meanings weaken interoperability.
People are stilll wanting to do lots of different (and interesting) things
with PUBLIC identifiers. That's fine, and a good thing.
They are wanting to do such drastically different sorts of things, though,
that any given document may well work only in a single XML application.
That's not so good.
Luckily for us, since CATALOG is optional, we can still use extid.map for
XML software sold by SoftQuad, for example, and use "fred.rls" as a
system identifier, so that's fine. At least, it's fine as long as you
don't want to share your XML files, e.g. by putting them up on the web,
and the files would be legal, so it wouldn't be our problem.
But would the market really decide?
I don't see many people choosing which SGML tools to buy based on the way
they use PUBLIC identifiers. Instead, they complain to technical support
after the purchase if it insn't what they want :-)
So I still think that we need a single, firm, precise, concise specification
for how this all works, that it must not be opptional, and that since
we are already well past our one week's work for a cs grad, we should
simply drop PUBLIC and CATALOG.