Re: DDH subdirs, URLs, and URNs
Hello Adam.
On Mon, Jul 06, 1998 at 04:59:16PM -0400, Adam P. Harris wrote:
>
> Marcus, I have a question about the DDH system. As I understood our
> last discussion of this issue, the DDH tree was centrally maintained,
> which means that it's not possible for doc providers to create new
> nodes in the tree.
Yes, I would prefer that, especially in the beginning, where I have to make
some changes etc.
> However, we did see that it might be nice to have 'application'
> groups, which are leaf nodes (meaning can't have child nodes) on the
> tree.
Yes. A package should be allowed to make a leaf section under the
condition that all documents below cover the very same or similar topic.
(For example, all user manuals for a single application, not one user one
devel and so on).
> However, my current Metadata proposal doesn't accomodate this
> at all. Unless we could iterpret the top level of my relative URLs
> (URNs) as an application group.
With a limited set of optional elements allowed then.
> Suppose that the Identity: field is reformulated slightly as follows:
^^^^^^^^^
"Identifier:" ?
> 1) if the file is located in the doc dir of the package <pkg>, i.e.,
> /usr/share/doc/<pkg>/<remaining-path>, and <pkg> is the package
> that *supplies* the resource, then it is appropriate to use a
> relative URL formulated as "<pkg>/<path>", where <pkg> is the
> package name, and where <path> is the location of the document on
> the file system relative to /usr/share/doc/<pkg> or /usr/doc/<pkg>,
> in that order
>
> 2) if not, use an absolute URL
>
> Benefits:
> (a) trivial to redirect SGML references (for example) to uninstalled
> packages to, say, a Documentation home page or resolver service
> on the web
>
> (b) no change in ID when moving from FSSTD to FHS, so no chance for
> wierd orphaned resources
>
> Then we might also use the first component of the relativized, case
> (1) URL as an "application group", at the discretion of the display
> system itself.
>
> Is this enough functionality?
I don't think so, but maybe I don't understand. I think it is perfectly
valid to access files with <pkg>/<path> without creating an application
group (how could you differentiate this from case 1 above?). On the other
hand, multiple application groups could be created (on in the user tree,
one in the devel tree for example).
Unless I didn't understood what you wrote above, this can't be achieved by
your proposal.
I'm not familiar with all RFC standards you use in your proposal. Would the
following be usable:
Identifier: ddh:/debian/support/bugtrackingsystem
Title: This is a subsection
Description: In this subsection, you find more information about the BTS.
Identifier: package/document.gz
Subject: debian/support/bugtrackingsystem
Title: whatever
Format: text/plain
This raises all sorts of problems, I know (conflicts, depends, etc).
But I think we need the following functionality:
1) Multiple Subsections allowed (but not nested in each other).
2) sigle files
3) mixtures of 1 and 2
4) Providing Titles and Descriptions of Subsections in different languages.
5) The frontend should be able to determine if a section is ddh or application.
In my picture the subsections are very integrated in the DDH. Tell me if you
don't think so, and we can flatten my model somewhat.
Also look at the examples in debian.ddh.examples, especially apt,
kernel-package and bts.
Thank you,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: