Re: B.9 Formal system, public identifiers?

[Gavin, beginning with a quote from James:]

| >For XML 1.0, we need to keep things as simple as possible.  The simplest
| >solution is:
| >
| >- No public identifiers, formal or otherwise.
| >
| >- System identifiers must be URLs.
| I disagree. Using FPI's and FSI's for naming is simple enough.
| The really hard part is name *resolution* (ie. turning a name
| into a physical adress that can be accessed).
| I agree that we cannot solve the resolution side by November, but
| XML naming conventions certainly can be resolved by then. Again,
| if we have an extensible naming scheme with a robust grammer, then
| I am all for it.

Putting on a third hat this time...

(Note that I am now speaking as one with a vested interest in this

In the general scales-to-the-edges-of-the-galaxy scenario in the
context of which this is usually discussed, the resolution problem is
a well-known nightmare.  In the more limited case where one is only
interested in defining location-independent identifiers for a few
thousand publications and only needs to resolve those identifiers
within a corporate intranet space, however, the resolution problem is
a pussycat.

At Sun, we are putting into place an intranet publishing solution that
relies on FPIs and the SGML Open catalog system (including Tauber's
DELEGATE extension) to provide location-independent naming of our
technical manuals and other publications.  This system allows users to
install individual publications in multiple locations on a network
without worrying about what happens if one of the servers goes offline
for a while, and we believe that it will provide very substantial
document management benefits moving forward.

We don't expect everyone to follow our lead in this, but it would be a
good thing for us to have FPIs as they are currently defined be part
of what you can legally put in an XML document.  So this (not
disinterested) user strongly supports Gavin's position.