Fried Parrot Intestines in my XML Soup

> If the defined method of resolution is "resolve as URNs", which
> various systems may do variously but with the same results (unless
> some succeed and some fail), does that suffice for you? 

For me it doesn't, because
(1) an FPI isn't (last time a checked) a full valid URN (e.g. lacks the
    urn: prefix)
(2) you can use URNs in the SYSTEM identifiers if you like.

There is obviously a lot of emotional attachment to formal public identifiers.

In some cases perhaps it's because people think that resolving an FPI always
gets you the same data,  It doesn't.  There isn't even a resolution mechanism
defined apart from Write a letter to ISO or the GCA.  The CATALOG mechanism
only helps you tie together an FPI and some data once you have already used
some other mechanism to fetch the data -- e.g. typed it in probably mostly OK
from the SGML Handbook or the Annex or the JoanSmithPinkThing.

It is true that a way to refer to commonly available files (DTDs, entity sets,
the SunSoft logo :-), notation definitions perhaps) in a way that would
allow a lookaside cache is useful.  We include a number of common entity sets
and DTDs with SoftQuad Panorama, so that if you put something on the web
with one of those DTDs, the user doesn't need to download it... and the
software knows that.

That's useful for SGML and Panorama.
Would it be useful for XML?

If so,  we need to consider a mechanism to do that in XML.
It could be with FPIs.  It could be with URNs.  It could be something
entirely different.  First we have to understand what we are trying to
achieve,and only then consider how to do it.

Other people use FPIs as a kind of indirection, so that filenames are
not wired in, e.g. in case the installation in <VOL4>EUROPE>SGML>SW.DIR;3
(Is that a valid PR1MOS networth path?) is moved.

This is a different purpose, and although the same mechanism might solve
both needs, it might also be appropriate to use two mechanisms.
It's done in C, for example, with a file inclusion path:
#include <stdio.h>
looks in a per-installation standard place (or places) for the file
"stdio.h"; you can add more directories to the list, e.g. with -I on
most C compilers, or in a dialogue box for preferences on some systems.
#include "stdio.h"
looks (by default) in the same place as the file containing that line,
like a relative/partial URL.
I am not here proposing C's semantics (or syntax!) for XML, but only
pointing out that there are other mechanisms.

We have focussed in very closely on FPIs, but I don't think we've
talked enough about what problems we are trying to solve.

For those of you who think it's a fought-and-won battle, I can only say
that there mere fact that everyone didn't immediately say yes indicates
that this isn't so.

Hence, I suggest that we need the following:
* a list of required functionality
* discussion of possible approaches to providing that functionality
* final choice of mechanism(s)
* discussion on syntax, if needed
* final shoice of syntax

Lee

Received on Monday, 2 December 1996 15:53:47 UTC