Re: FPI resolution
> | http://www.ucc.ie/cgi-bin/PUBLIC?-//IETF//DTD_HTML//EN
> That worked for me in Spyglass, although the DTD returned was v1.28, whereas
> my local copy (from the RFC?) is v 1.30. This is a pretty illustration
> of the scope of variability created by generic rather than version-
> specific FPIs (and for that matter URNs).
Yes, I just stuck in there whatever I happened to have around for the
moment :-) My 1.30 is HTML 2.0 Strict, the 1.28 is a version regenerated
from within Near&Far (if anyone has an untouched 1.28 please mail me).
> This particular problem is
> due to the HTML specification, which Peter has implemented correctly,
> I think; contrast what happens if you ask for -//Davenport//DTD DocBook//EN
You should get a list of DocBook FPIs unless you put an underscore
between DTD and DocBook,
> (Davenport has never published an FPI for DocBook without a version
> number, if memory serves).
There is one DocBook file without a version: dbgenent.mod, which is
referred to in the drivers for 2.4.1 and 3.0 as
-//Davenport//ENTITIES DocBook Additional General Entities V3.0//EN
> Also note that this URL gives you Peter's version of the file, rather
> than the version (if any) published directly by the owner of the owner
> identifier. It says "this is public text for which www.ucc.ie is
> offering resolution." Peter could implement redirects to, e.g.,
No, this is my error. I just dumped into the directory what I had on
hand. This is proof-of-concept, not a production service. I would need
to build the stuff from original copies to be more accurate.
> the Davenport site for the DocBook DTD if that seemed to him a more
> reliable way to achieve resolution, but he might equally conclude
> that maintaining local copies is a superior method.
No, you're right, it ought to be the canonical copies. I just now
refreshed DocBook from source, so they ought to be OK now.
> Now if Peter offered resolution using the SYSTEM keyword, it would be
> clearer that that you would be getting his local copy (although he might
> fall through to public resolution if he doesn't have a local copy); still,
I toyed with SYSTEM, but the whole point is that SYSTEM now seems to
be implying either
"you ought to have a local copy of this file, that's why I'm
giving you the filename"
"here's a URL, go fetch it"
> I can't see that he's doing anything untoward with PUBLIC. What is
> interesting here is that the mechanism of resolution and the results
> might be the same either way.
I can't see any way to resolve SYSTEM ids in this context. DocBook 2.4.1
distribution tarfile contains a file docbook.dtd and so does the 3.o
tarfile. No implicit or explicit directories, so a user requesting
resolution of the SYSTEM id "docbook.dtd" is not supplying sufficient
information for accurate resolution. I guess a server could easily say
"I will supply the most recent version known to me", but I don't think
that would fly in a production environment if a user was trying to
parse an instance which was actually 2.4.1 but she was being given 3.0
from a SYSTEM server.
Having both PUBLIC and (implicit) SYSTEM ids means any server would need
to be written to prefer one or the other when both are supplied, and it
seems to me that in this case the SYSTEM id is simply redundant.