Re: The furore over PUBLIC

On Thu, 27 Mar 1997 18:25:15 -0500 Paul Prescod said:
>> PUBLIC makes that go away.  Sorry, but you can't sweep it under the
>> rug, and I repeat: everything you can now put in an XML document has
>> a *single* straightforward interpretation such that implementations
>> should really interoperate first time, every time.
>
>What about alternate text encodings? What about processing
>instructions?  In both of those situations we recognized that systems
>smaller than "the entire internet" might have special needs and we
>put in "hooks" for them to do their thing within the generally
>interoperable framework.

Alternate character encodings (not, in my mental dictionary, text
encodings) are a good example.  Note which of the following three
positions we took:

  1 fixed encoding:  everything in UTF-8 (alternate form:  everything
    in UCS-2)
  2 anarchy:  no requirements, processors do what they like
  3 required minimum which all processors must support; nothing to
    prevent them from supporting more.  If I know that *the processor(s)
    I care about* support the encoding I like, I can use it.  If I
    care about having *all* processors be able to read my docs, I
    know what to do, and I can ensure that all processors can handle
    my docs.

Having a public identifier without a resolution mechanism is very
like having no rules at all about character encoding.  Nothing to
prevent you from doing what you like in the processor you write
yourself, and nothing to prevent your *having* to write your own,
because nothing you can count on being present in every conforming
processor.

I have a question for the WG members who want PUBLIC to be syntactically
legal, but don't want to specify even a non-exclusive minimum
resolution method.  Serious question, not sarcastic (despite the
tone).  Why bother?

If PUBLIC is not allowed, I agree life will be tough for you.  You'll
have lots of non-conforming data that would be conforming if only PUBLIC
were legal.  You'll have to write your own software to support XML.  On
the plus side, you'll be able to write in whatever resolution mechanism
you like, including the ever popular sequential-search-through-the-Web
and the shell-out-and-search-altavista-for-the-FPI method.  On the minus
side, you'll have to do it yourself.  So I agree, life will be hard,
though perhaps still worth living.

What I don't understand is this.  How would this picture change if
PUBLIC were legal in XML, without a standard resolution mechanism?
You'd still have to write all your own software, you could still share
it with friends, your friends would still be able to use it only if they
agreed with you that searching Altavista was an OK method of resolution.

What's the advantage to you, to your users, or to XML if the XML spec
says PUBLIC is legal, without saying how, when a processor needs an
entity declared with a PUBLIC identifier, it is to find that entity?

You can say your data is conformant?  True.  You can say your parser,
which doesn't actually do *anything* with PUBLIC identifiers, is
conformant?  Also true.  But what does that get you?  If conformance
means that as a publisher you can ensure that all conforming parsers can
parse your docs, it's worth worrying about.  If it doesn't guarantee
interopability, why is it worth worrying about?

I guess I think one point of defining standards is defining interfaces,
and one point of defining interfaces is to ensure that products from
different vendors can support the same interface.  (There may be more to
it than this, but I can't think of anything else off the bat.) This
means (a) they can interoperate, and (b) I can junk product X for
product Y when I like.  Lose interoperability, and you seem to lose this
entire ball game.

If you don't care about interoperability, why do you care about
conformance?

Serious question.  I've decided I don't understand your position very
well, after all.

-Michael

Received on Thursday, 27 March 1997 19:27:29 UTC