Re: FPI's in NOTATION declarations
Ken Holman <firstname.lastname@example.org> wrote:
> A full ISBN can be used in an FPI to refer to a concept by pointing to
> an instance of publication of that concept. The NOTATION declaration for
> TeX could be:
> <!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, except that the URL can
be resolved right now today algorithmically, whereas the FPI can't.
(the SGML OPEN catalog can be used to turn an FPI into a URL, though).
> In these cases one is not trying to dereference a location, rather, just
> trying to dereference a concept or specification. I don't think that a
> SYSTEM identifier with an URL would suffice for this.
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'tneed to dereference it.
I don't think it's useful to talk about FPIs that you don't want to
dereference (even indirectly) since any string at all would do equally
well, so a URL would do.
So let's focus on the cases where the FPI isn't just a string you want to
be unique (which you can do reliably with a URL) but instead on other uses.
 compatibility with HTML
 server-side indirection
 client-side indirection
 client-side file inclusion
 I think FPIs have one major application for XML:
<!DOCTYPE HTML PUBLIC "-//ietf//DTD HTML 2.0//EN" "html.dtd">
would become legal XML, so that there could be documents that were
legal in both XML and HTML, which is not possible right now.
Actually if the XML PI is illegal in HTML 2.0 and the SGML declaration
differs in other ways, perhaps that's not sufficient.
 you can get this already with URLs.
 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.
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.
However, I would rather see this as a separate document and be suggested
than see it as required. It's not needed for a spreadsheet file load,
nor for many other XML applications.
 (client-side file inclusion)
If you download a file using a URL, relative paths will work fine for file
inclusion. You can generate them automaticallyif you have a tool to do it,
or write one. The same look-aside mechanism as for (3) (askance.map??)
might be useful.
If you mantain a large site, you may want indirection of links.
You can do that by putting all the link entity definitions in a central
file, though, using existing XML mechanisms.
Many people are asking for FPIs because they are a mechanism for doing
something they need to do. But there are other possible mechanisms.
The only argument that sways me here is the compatibility with HTML one.
Am I missing something?