Re: FPIs to URNs

Reading Ron's message of 11/22 once again, I suddenly realized that
one of the major reasons I was having trouble visualizing the
scenarios that he describes is that what he calls a "client" is, in
our system, a specialized HTTP server process.  As you will see in
greater detail when I find time to describe it, the Solaris 2.6
AnswerBook2 document system that replaces our traditional AnswerBooks
is based on a mutant Web server (a customized version of DynaWeb)
implemented as an optionally installed Solaris daemon whose only
function is to serve out SGML-based documents to Web clients.  It's
this daemon that manages all the FPI resolution, not the Web browsers;
all they ever see is weird-looking URLs.  So when Ron says, for
example, that a client consults the local catalog, read "AB2 server"
for "client".

A consequence of this is that in our FPI scheme, *no* logic is added
to the client application itself.  (It couldn't be; the whole system
is built around the capabilities of current HTML browsers.)  The same
would hold true if our server were talking to some future XML client.
In our system, name resolution is always a server problem, not a
client problem.

A further consequence (speaking again only for Sun's contemplated use
of FPIs) is that, for our purposes, FPIs need not be included in XML
at all if XML is used purely for document delivery, just as FPIs are
not now included in HTML.  They only need to be allowed in XML if XML
is going to live in its native state on the server, and then they only
need to have the same status that they do now in SGML -- dumb strings
with a known syntax.

Of course, other people may have completely different ideas of what an
XML client should be doing with an FPI, and I'm not denying that it
might be very useful for all of us to nail down expected behavior with
regard to SGML Open catalogs.  I'm only saying that for my own
company's purposes, it is not necessary to specify or require any FPI
resolution capabilities for XML, it is only necessary to allow FPIs as
syntactic objects.

Jon

Received on Tuesday, 3 December 1996 13:15:53 UTC