Re: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> Fine, your proposal, but haven#t we talked about an open solution
> developed by several people?
>
> Why have you changed the whole concept without asking the other developers
> :((?
What do you think the email was intended for?
It's not set in stone. Not at all. I posted it here for comments. I
wanted to clearly state my position, which took a while. The last
time I posted a spec I wasn't clear enough and it wasted a lot of my
time clarifying things in email exchange.
So please, Marco, critique away!
> APH> Marco, would you be willing to help me work on the API and thinking
> APH> about how to attach a database backend a la dhelp ?
>
> Arhhh. Could we please finish one thing before starting another? At first
> we need a *file format*.
I defined the file format.
> APH> * work out the install-docs hooks mechanism for backwards compat
> APH> support of dhelp and dwww
>
> We don#t need that for dhelp. As I#ve said several times, dhelp will parse
> the new file format itself.
Excellent. I know that. I said for "backwards compat", i.e., for old
versions of dhelp, or for dwww.
> APH> * work out the API for a better (no shadowing of data required)
> APH> dwww/dhelp etc working right out of the document store (I need
> APH> lots of help here)
>
> I#m not interested in such an API for dhelp, because I need a special
> structure. And we had discussed this already: dhelp will read the docreg
> files itself.
I don't know whether I agree with this or not.
> APH> This manual contains a guide and a reference to the Debian Metadata
> APH> Project.
>
> A single person project :(?
Aren't you contributing here and now?
What exactly have I don't that you are complaining about Marco? Just
relax! Anyhow, for anything to get done period, there's always a
single person forging ahead. Like I said, I'm here to debate how to
do this, and it can't work if I don't have people like you feeling
good about the spec.
> APH> 3.1.2. The SCHEME Qualifier
> APH> ----------------------------
> APH>
> APH> The `SCHEME' qualifier indicates what notational scheme the content
> APH> is encoded in. This qualifier is usually not available to the
> APH> maintainer for manipulation, since there is only one reasonable
> APH> scheme for an element in the Debian environment.
> APH>
> APH> The default scheme is generally `freetext'. Other elements have a
> APH> scheme of `URL' or `ISO.636'.
>
> Whatfor does we need this?
It's not user editable. It's implied on a per field basis.
Basically, it sets constraints on what can be in a field. I.e., if I
have a field that is supposed to be a URL, it must follow URL syntax.
> APH> installed). In such cases, for the ease of the maintainer, a
> APH> relative URL may be used. The implied basepath in such cases is
> APH> `file://localhost/usr/doc/'.
>
> No. We had discussed that topic several times.
Yes, but I didn't agree with you. Please put forth an alternate
proposal, one which will work well considering our desire to have
these ultimately be specified as URNs and served off either the local
machine or off a web server (i.e., out of the DDP web pages).
> APH> Currently, the domain of allowable values is
> APH>
> APH> * howto
> [ ... ]
>
> I don#t understand that. We don#t need that, because for this purpose we
> have got the section tag.
Not as I read the DDH. Anyhow, it's an optional field.
> APH> * Subject
>
> Why have you changed the name of this tag?
To comply with Dublin Core. I'm willing to talk about the wisdom of
using an industry standard or our own proprietary tag set, but I
haven't seen a single good argument to use a proprietary tag set when
perfectly good standards are available.
> APH> * Rights
>
> Do we need this tag?
Again, it's optional.
> APH> A URL used to uniquely identify the resource. If the URL is a
> APH> relative URL, it is relative to the location
> APH> `file://localhost/usr/doc/', as described in subsubsection
>
> No, the local URL should relative to the positing of the docreg file. For
> example a user could use dhelp to build a structure of his own documents.
>
> APH> Title
> APH> LANG
> APH> can set
>
> Not necessary, the title should be in the language of the document.
!! Duh! That's a good point! I guess you're right that there's no
point on translating the title of an english document into German, is
there?
> APH> docreg files must be placed in the `/usr/share/doc-base/docreg/'
>
> No, no, no. This makes it impossible to use docreg with relative paths.
> I#ve showed you the disadvantages of this solution several times. This is
> a very bad solution.
Sure, you've said it many times, but you never convinced anyone else
that it was a good idea. I'll review your arguemnt in the mailing
list and try to address you points, it seems that this is the only
major sticking point you have.
If I recall, you would prefer to have docreg files in the
documentation area, i.e., /usr/doc/<pkg>. I am amenable to this,
actually, but if you're going to be reading docreg files directly, I
think this is going to be evil.
One thing I want you to keep in mind that hamm's /usr/doc/<pkg> will
be slink's /usr/share/doc/<pkg>, AFAIK. Docreg files should not need
editing to deal with this. This relates to the URN issue.
Personally, there's an easy way to resolve this. Someone needs to
study URN spec more, and we must do what it will take to transition to
URN or use URN right from the start. Any system which will make it
*harder* to move to URN is unwise, IMHO.
> APH> subdirectory. By convention, this file should be named the same as
> APH> the package, i.e.,
>
> Sorry, but a lot of package will include more than one docreg file.
See below!
> APH> is not enforced; however, these file names must be globally unique
> APH> across all packages.
>
> Right and this is one problem with this solution. What#s your problem with
> my solution: docreg in /usr/doc/<foo>?
Like I said:
(a) I don't really care that much
(b) any scheme *must* allow us to serve documents off other servers,
i.e., debian DDP web area
(b) all identifiers for documents *should* allow us to transition to a
URN scheme very easily, if not use that from the get-go
If you can restate your entire scheme for 'Identifier' and for docreg
file placement, and show how that addresses points (b) and (c), I will
adopt it.
> APH> The Document Store, in `/var/state/doc-base/docstore', is a file
> APH> containing the collected information about all documents currently
> APH> on the system. This file is in the same format as the docreg files.
>
> ???
Doh! This is a mistake, thanks for pointing it out!
> 1.) This docstore is the database of *your* docbase program. It shouldn#t
> be part of a file format standard. Sorry.
> 2.) Why should we store one information twice?
I'm willing to dump the document store concept entirely if you, as the
dhelp maintainer, thinks it's not going to be useful. Hey, it just
makes my life easier!
> APH> The Document Store file may be processed by the doc-base system into
> APH> a more optimized system as well, such as Berkeley database file. To
> APH> be determined.
>
> This is not part of the file format -> remove it
Ok, will do that for now.
> I#m missing the tags for adding new sections and their description.
Yes, that's not part of the docreg spec per se. The DDH is a "SCHEME"
for our subject tree. (Other schemes, i.e., dewey decimal system, we
do not use).
Marco is working on this. I'll probably help him with the definition
of the file format. It's pretty straight forward, it's not in a
standard format because there *are* no such standards AFAIK, and it
hasn't changed much.
> Please tell me, if you#re interested to develop one common file format for
> all programs or not. At the moment I#ve got the impression, that you#re
> developing something for your system.
I want it to be for everyone.
> If you#re interesed in one format you should add the proposals of the
> other developers. If you#re not interested, I#ll create my one file
> format.
>
> We#re talking about a very small file format for several month without any
> results. This is really bad.
We *do* have results! Pretty much, the docreg format, and the element
list, is complete. You might not agree it, in which case it may need
modifications.
I'm sorry you feel discouraged by what I put forth. That saddens me.
I hope we can work out our differences, Marco. Although, frankly, if
you *do* object to the docreg format as proposed, I didn't see any
substantive critiques in your email. The only critique of the format
as I see it is the placement of files, and the scheme we use to refer
to resources.
Here are my questions for you?
Why do you not like the docreg format?
Why do you object to using a leading industry standard, which has
covers *each* of our requirements?
What features or tags do you need that are not there?
--
.....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: