DDH subdirs, URLs, and URNs
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.
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. 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.
Suppose that the Identity: field is reformulated slightly as follows:
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
(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
Is this enough functionality?
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com