Re^6: Debian Metadata Proposal -- draft rev.1.4
Am 09.07.98 schrieb Marcus.Brinkmann # ruhr-uni-bochum.de ...
Moin Marcus!
MB> Now to the DDH. The DDH implements ordering as in "b)" above. There is no
MB> natural place for displays of "howto"'s or "faq"'s. This is only natural.
I don#t think so. We#ve got the same problem with RFCs, books, etc. This
documents don#t fit in your DDH structure in a lot of cases. This
documents will have only a type but no subject line in your proposal.
MB> If you really can't see the distinction between "Subject:" and "Type:", I
MB> beg you to believe Adam, me, and other people, who can. I really tried to
MB> explain it multiple times now.
I can see it for the WWW and for books. But I don#t think that#s the right
solution for our system. Please keep it mind whatfor the DC standard was
defined. The system is designed for the global WWW and not for local use.
For example they don#t have something like the DDH. They use the Subject
line for key words and not to build a document "tree". That#s the reason
why they need "Type:".
MB> information. I don't understand why you think the Type tag would be
MB> inconsistent. Is this just a personal feeling or a technical contribution?
It#s both. For the user there#s no difference. What#s the advantage for
the user. I don#t have an idea.
MB> "Type:" is an optional tag. Documents that clearly have an associuated
MB> type (as howto's and faq's) will carry it. Other may not.
Again, whatfor do we need it. Examples?
MB> I don't think it's add complexity, it's just another, optional, field. I
MB> think mainatiners would be more confused by howto and faq section in the
MB> DDH.
I don#t think so. They#re Linux "standards". Read the newsgroups. People
don#t talk about "Firewall documentation" but about the "Firewall HOWTO".
MB> > 1.) With your solution you can only support one subdir (/usr/doc).
MB> > But we should offer support for every location (for example
MB> > /usr/local/doc).
MB> ? We do support every location that complies to URL standard. We just
MB> don't support it as relative link. One can always use absolute paths.
Can he? Example: my package will add /tmp/foo/test.html. How should dhelp
show this document? Please read the webstandard 3.0. We could never
support all subdirectories.
MB> > 2.) With your solution we will have a problem to move from
MB> > /usr/doc and /usr/share/doc, see (1).
MB> Not really. There is a good work-around for the transition perio (scanning
MB> both directories).
This is a bad solution.
MB> > 3.) Commercial programs my include docreg files under /opt, see (1).
MB> So what? See (1).
They don#t know where the user will install the program. Your absolute
paths won#t work.
MB> This isn't about html at all!
Well, our prefered document format is HTML! Read the policy.
MB> We try to define a metadata
MB> standard. The metadata standard
MB> consists of a plain ascii file.
HTML consits of plain ascii, too. Why shouldn#t we use good ideas from the
HTML standard?
MB> The location of an ascii file in
MB> the local file system should not
MB> make any difference!!! I think a
MB> data file concept where the stored
MB> data changes meaning when the data
MB> files are moved is heavily flawed.
I don#t understand that.
MB> Marco, how would you implement
MB> the relative path in database re-
MB> pository?
I#m not sure. This depends on the next proposal. At the moment I#m storing
the path relative to /usr/doc.
MB> The docreg files are parsed, and not "executed" like html pages. So they
MB> should be as unambigouus as possible.
I don#t see a difference.
MB> Proposal: Let's drop the relative link concept at all. Every docreg file
MB> should specify the whole valid URL, then we avoid all problems (including
MB> the problems with the file system transition).
I don#t vote for this solution. I can#t see any advantage using absolute
paths.
MB> In the database, the real path has to be stored anyway. Adam?
No.
MB> I think this is a misconcecption for a metadata concept. It may be useful
Why? Would you give a book a new ISBN number if you move it to another
room?
MB> not for abstract data files. I don't want the content of the docreg file
MB> dependent on the location in the file system. See above.
I propose to have URL and ID fields.
cu, Marco
--
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com http://www.tu-harburg.de/~semb2204/
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: