Re: What to do given both SYSTEM and PUBLIC?

At 12:52 PM 02/18/97 -0800, Joe English wrote:

>If this happens, it means that the document's author
>has assumed that the recipient already knows how to resolve
>the PUBLIC id.  So the recipient's software should try to
>resolve it.  If the PUBLIC id can't be resolved, then the
>document's author's assumption was incorrect.  We don't need
>to specify error recovery in this case.

So far I agree....

>
>
>> * what to do if you are given both
>
>Try to resolve either one.  If that fails, try the other.
>It doesn't matter which one you try first.

So two systems that do opposite things are both conforming? That seems very
ODA-like (I take that as a negative): "your system can do either the logical
structure, or the layout, or both" -- so immediately you end up with
non-interoperable yet conforming systems. We should at *least* do what SGML
Open did and requir systems to support both and give a way to configure the
choice, even if we can't come to a single decision.

>
>(If the software does not know how to automatically resolve
>PUBLIC ID's -- which I suspect most software will not, since
>_nobody_ is sure how to do this yet -- then naturally it
>should try the SYSTEM ID first.  Is there a need to put
>this in the spec though?  It seems like common sense to me.)

If it never tries the PUBLIC because it doesn't know how, then it seems odd
to me to say that it should "try the SYSTEM ID first" -- One could just as
well say it "tried" the PUBLIC ID first and failed (remarkably quick
failure, that), and then went on to the SYSTEM. Your local uncertainty
principle at work.

>
>
>> * what to do if you are given both and the resulting files are different
>
>This means that somebody somewhere has made a mistake.
>We don't need to specify error recovery in this case.

I'll buy that; but you'll likely never *discover* the error, since if you
successfully resolve one ID it is unlikely you'll bother with the other.


>Such systems will naturally have to be very good
>at automatically resolving PUBLIC IDs, which will be
>tricky, since nobody knows how to do this at all yet.

Overly strong, I think. There are many schemes that are known to work, and
it is more a question of choosing than of determining feasibility. Walk into
any bookstore with an ISBN in hand, for example, and in a few seconds (maybe
a minute if they're on a slow modem) you'll know all the publication info,
and probably what shelf it's on if it's there, or which branch of the same
bookstore chain has it. Or send email to a DNS address, and usually it gets
there. Table lookup is not a big deal, even for huge tables; and there is a
lot of knowledge in CS on how to distribute such tables.

Steve

Received on Wednesday, 19 February 1997 11:11:41 UTC