Re: FPI's in NOTATION declarations

Ken Holman <gkholman@microstar.com> 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
> TeXbook//EN">
[...]

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 --
	concept://computing/text-formatting/programs/TeX
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.

[1] compatibility with HTML
[2] server-side indirection
[3] client-side indirection
[4] client-side file inclusion
(what else?)

[1] 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.
 
[2] you can get this already with URLs.

[3] 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.

[4] (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?

Lee

Received on Thursday, 28 November 1996 19:22:00 UTC