Re^20: Debian Metadata Proposal -- draft rev.1.4
Am 16.08.98 schrieb apharris # burrito.onshore.com ...
Moin Adam!
APH> > Of course it#s necessary. I#m sorry, but I don#t understand why you
APH> > like your proposal. There#re several cases where your system will not
APH> > work. Maybe my proposal mixes metadata and resource IDs, but where#s
APH> > the problem? It solves a lot of problems.
APH> Please name example cases. I've outlined many cases where your system
APH> will brak.
My system doesn#t break. It#s always possible, that a maintainer releases
a buggy .docreg file and such a file could always produce problems. But
these problems occur with both solutions!
My problems with your solution are:
1.) I need a unique ID.
2.) The relation tags shouldn#t refer to a file name, because this
file name could change every release of the package.
And both problems are solved by my solution.
APH> Bullocks, it has to be robust and well designed.
And it should be finished before 2030 :).
APH> It has to scale. It
APH> has to fit future, unanticipated needs.
I think that my proposal is robust. And I don#t think, that using a file
name as ID is a good design.
APH> Believe me. I design and architect s/w for a living. Restricting
APH> yourself at the outset to "good enough" always fails.
That#s right.
APH> > And you#re proposal doesn#t satisfy all needs.
APH> Yes, it does solve the needs which are within it's scope.
Not really.
APH> > If the local file doesn#t exist it#s a bug! Why should a package
APH> > install a metadata file which refers to not existent files?
APH> It could happen if the local sysadmin removes extraneous
APH> documentation, i.e., without removing the package. It could happen if
That#s why your docbase package should offer a db rebuild option like
dhelp. Once again, it#s always possible to destroy the db.
APH> It doesn't try to solve the persistence of files on the local file
APH> system. I submit now, as I always have, that this perisistance
APH> problem is *not* solvable within docreg itself.
Once again, why not? If a maintainer changes the ID every release this is
a bug of the package!
APH> > And maybe you would like to refer to more than one file in such
APH> > a directory.
APH> Simply not allowed, nor needed.
That#s your opinion.
APH> > Because my solution is a better design? I don#t understand why we
APH> > should use a filename as identifier. This is not part of the DC
APH> > standard.
APH> It *is* part of the standard to use standard URIs for the Identifier
APH> and Relation.* elements.
They suggested to use ISBN numbers or URLs, right. But this is only a
suggestion and it#s a really bad suggestion to use URL. Do you need
another example:
1.) Someone writes document a.html
2.) Two people install the same document on their WWW servers.
3.) With your proposal/DC suggestion we would have two different
identifiers for the same resource:
http://1.de/a.html
http://2.de/a.html
And this should be a good design?
APH> > Why not? By the way who uses DC at the moment? In the WWW most people
APH> > use the HTML 3.2 metadata format. And in the WWW metadata are always
APH> > part of the document.
APH>
APH> Yes, I want to support being able to do this:
APH>
APH> install-docs -i /usr/doc/jade/index.htm
APH>
APH> And if this file has metadata in it, we read it, and voila. No need
APH> for a docreg file at all.
Sorry, but this is not possible!
1.) The DC format in HTML is not the same as in our file.
2.) The maintainer has to change most tags! The upstream maintainer
will always use other Subjects, IDs ...
Please offer a html2docreg script that could be used while building the
package.
( I#m working on a sgml-tools patch, to support DC )
APH> > ??? We#re talking about a doc system for Debian. And all Debian doc
APH> > packages are maintained by Debian. So where#s the problem?
APH> Maintainer ease of use. Suppose DC catches on and lots of developers
APH> start using it, either within HTML or SGML or whatever. Why impose
APH> additional burden on maintainer to maintain this.
I don#t understand this problem, I#m sorry.
APH> Most of the documentation on a system is *not* debian specific.
That#s why we need something like sgml2docreg, html2docreg.
APH> Title: Debian Heimeseite (LANG=de)
But we have agreed to remove LANG= from our standard.
APH> No, it's necessary that these elements use URIs. If you want to
APH> establish new URI schemes, i.e., debian-doc:foobar, then hoorah. But
APH> you'll have to manage it outside of docreg. Because it *can't* be
Why? It should be used only in docreg files.
APH> managed within docreg. See the counter examples in other email.
Sorry, but I don#t see any real problem.
APH> Impossible to write unless the docregtest script has access to every
APH> docreg file in debian, which is also impossible.
? docregtest should be part of dh_docreg.
cu, Marco
--
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com http://www.tu-harburg.de/~semb2204/
Reply to: