On Thu, Jul 09, 1998 at 02:55:18AM -0400, Adam P. Harris wrote: > > I'd like everyone to take a step back and relax. I'd like to thank > everyone for participating, and the rest of the debian-doc list for > onlooking. Remember, we're all volunteers here for the fun of it.
<breath in><breath out><counting from 1 to 10> Feel better now, thank you ;) > Identifiers composition: > > Marcus' straw man: Identifier is always absolute URL > con - FSSTD to FHS transition requires docreg edits > con - not really a serious proposal ? It is not a serious proposal. It would solve all problems, but is unnecessarily extreme, because I think the APH's URN proposal is clean and doable. If no satisfactioon can be achieved by your or Marcos proposal, you may want to drop the relative Identifier completely, which would lead to my "sort-of-proposal". Let me say: Keep in mind that you don't need to provide relative identifiers. KISS. Although I personally favour the URN scheme, I would not abandon my "sort-of-proposal" to soon. In the long run it is simple and easy to understand, and I don't think changing the docreg file once is too much hassle for the maintainer, who has to check all files for FHS comliance anyway. Important: This could easily be made a lintian check! > APH's URN: Identifier is URL, or a URN of the form > 'debian://package/<file relative to pkg doc area>'. > pro - FSSTD to FHS transition doesn't not require docreg change > pro - flexible URN2URL translation would allow use of central > document systems > pro - Identifier element is assured to be unique, at least within > the pkg, since it contains the package name Yes, and because a package is not considered to contain different /usr/doc *and* /usr/share/doc files with the same name. > con - requires a URN2URL processor of some sort, which would have > to gracefully cope with FSSTD->FHS This would be done in install-docs, before the document registration starts, when we have tools to access a database. As the discussion about the data base is postponed, every program reading the docreg file has to cope with it. > con - wordy (could we have an implied syntax that wouldn't > confuse people?) We would probably end up with the implied syntax "package/<file>". This is only confusing if the docreg file is also in the "/usr/doc" directory (because one could assume that it is a path relative to the position of the odcreg file). As long as it is pointed out that this will be relative to the doc directory regardless the position of the docreg file, everything is clear. > Identifier uniqueness: > Under debate. I would propose the following: each metadata must > refer to one and only one resource (URL or URN). However, a URN or > URN *may* have several metadata that refer to it. Will this make > display systems and data shadowing complex? Basically, metadata > identifiers would not have to be unique. As long as the quadruple of required tags provide a unique set of data,a one to one mapping can be achieved, and you can take this for tags as a unique doc-id. I don't think it is very likely that two different packages will ever provide a document with same idenitifier, Title, Format and Subject data. If this happens, the rest of the data could be compared if it is identical, too. It is important to keep in mind here that those four tags will tell us nothing about the relationship of two documents. Translations, format conversions etc. have to be marked elsewhere. Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.org master.debian.org [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
