Re: FPI resolution
Peter Flynn wrote:
| > | 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,
The HTML spec gives a series of more to less specific FPIs; the sample
you gave is an unspecific one, which allows a lot of scope for variation
in what gets returned by any service. I think you are doing a right thing
here, per the spec.
| > 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,
Right. You don't get a Docbook DTD file, because Davenport never did
what HTML did; the FPI in my example doesn't match anything.
If I do put an underscore in I get the same result.
| > (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
That's an ENTITIES file, so doesn't match the FPI I tested.
| -//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.
Sure, nothing wrong; the point is that this is kinda like URN resolution
and shows a few of the issues involved.
| > 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"
| Doesn't it?
In the context of this query URL, SYSTEM could be but need not be
thought of as signifying, "here's what Peter has on his system."
| > 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
I was thinking of
Your use of either SYSTEM or PUBLIC is unconstrained by any spec.
| 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.
I think PUBLIC is, too; if you need a keyword in the path portion
of the URL, you could just as well use FPI.
Terry Allen Electronic Publishing Consultant tallen[at]sonic.net
specializing in Web publishing, SGML, and the DocBook DTD
A Davenport Group Sponsor: http://www.ora.com/davenport/index.html