Re: FPI's in NOTATION declarations
At 07:22 PM 11/28/96 EST, firstname.lastname@example.org wrote:
>Ken Holman <email@example.com> wrote:
>> <!NOTATION TeX PUBLIC "+//ISBN 0-201-13448-9::Knuth//NOTATION The
>However, leaving aside the idea that the notation is supposed to refer
>to the program that will process the data, for practical purposes (avoiding
>intellectual elegance for a moment) one could do
><!Notation TeX Public "http://www.stanford.edu/programs/TeX/2.97/">
>and there would be no substantive difference,
There are substantive differences.
The first is that the first namespace is formally organized and "bigger"
than DNS, IANA or Internic.
The second is that FPIs can be "redirected" by the information consumer or
maintainer, where as URLs can only be redirected by the information
provider. If you are trying to validate an SGML document on a notebook on a
plane, that might be a useful ability to have. I suppose you could redirect
URLs, but that seems like a nasty semantic mixup. If an identifier has a
machine name in it, then the information should, at least logically, come
from the machine (even if a cache "represents" that machine).
>Possibly not, but since dereferencing a concept has no practical application
>that I can see, I don't care. You could use a URL for that too --
>would do if you don't need to dereference it.
Some people feel strongly that there should be a syntactic differentiation
between *names* and *locations*. A concept cannot have a URL. It can only
have a name, or perhaps a URN. I think that the first time you "click" on a
"concept:" you'll wish that they were distinct also.
Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think
that they should usually be used together.
> client-side indirection
> neither FPIs nor system IDs give you this on their own. Combined with
> the SGML OPEN CATALOG mechanism, you can get client side indirection
> if you know the public identifier in advance and hard-wire it into a file.
> This is useful in practice mostly because SGML tools are so badly broken;
> we vendors should all be embarrassed and ashamed at the thought that
> SGML OPEN was needed in order to allow interchange of SGML files even
> to the limited extent we have today.
Isn't that what SGML Open is for? Anyhow, I don't really understand what you
mean aobut SGML tools being badly broken. The problem FPIs partially solve
is *hard*. FPIs provide a partial solution that URLs do not.
> There is no reason why a client-side URL lookaside table could not be
> used to give this functionality with URLs.
> This could work like the Apache Alias directive:
> Alias "system-id" "other-system-id"
> where both system IDs are URLs.
As I stated before, I think that this is attempting to make URLs into
something they are not. I don't really feel comfortable having clients
redirect URL accesses. With a separate syntax it is clear from the document
that a redirection is possible, if your tool supports it.