Re: DDH subdirs, URLs, and URNs
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> On Mon, Jul 06, 1998 at 04:59:16PM -0400, Adam P. Harris wrote:
> > 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:" ?
Yes...
[...]
> > 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.
You are correct as usual.
> I'm not familiar with all RFC standards you use in your proposal.
Well, RFC 822 just defines the field syntax. The allowable fields are
defined by Dublin Core, but we can add new fields if we need to, at
the expense of course that that field won't interoperate with anything
non-Debian.
> 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
Yes, but...
> This raises all sorts of problems, I know (conflicts, depends, etc).
These problems are very nasty ones and I don't think we've engineered
the right solution yet.
> 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.
Yes, whatever we do, we need the LANG qualifier on each field for full
internationalization.
> 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.
Well, we probably all need more real-world experience before we can
decide whether we *need* application subgroups, and how best to
deliver them.
So I guess I would ask for more arguments and discussion on whether
and why and how we need "application groups". Which will be tough
until we get prototype systems working.
--
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: