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,
| 
| Uh?

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"
| or
|    "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 
   http://www.ucc.ie/cgi-bin/SYSTEM?-//Davenport//DTD DocBook//EN

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.


Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
       specializing in Web publishing, SGML, and the DocBook DTD 
                   http://www.sonic.net/~tallen/
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Wednesday, 19 March 1997 11:09:03 UTC