Marco, I read over your response again, and I'm trying to make sense of it.
As I read what you want, it's the following: a) metadata colocated in the directory of the documentation b) identifiers for files given relative to the location of the metadata file c) no centralized store at all, no API d) ddh data centrally located, stored in a documented syntax I don't really have any problem with (d) at all. As for (a-c). For one, less work for me as doc-base maintainer, the better. So that's a plus. Minuses: 1) how to find the definative list of metadata files? Impose a file naming convention like *.docreg ? 2) where would metadata files which refer, i.e., to offsite materials such as www.debian.org, reside? 3) the format would be highly restricted, in syntax and symantics. No decoupling between display systems and how metadata is encoded. Any change in the docreg file would mean all display systems would have to be hacked to deal with the new format. 4) also following from (3), no way to transition a new format into place. No way to deal with some files being in one format and one in another without a lot of parsing changes in all display systems 5) coupling the identifier with the docreg file location seems messy to me. 6) Not a scalable system. 7) Not well suited for an "indirection" method, whereby local documentation could be supplemented by documents at a central location like the DDP. This is important when you think about debiandoc-sgml and the capability to refer to metadata identifiers from within SGML. 8) Not well suited to say, using metadata to organize a Debian Documentation centralized site (i.e., DDP next generation) 9) Not well suited for transition to URN scheme (my scheme as it stands has problems as well there) Conceptually, the docreg file is just a file which is used to transmit metadata from a package into the system. We should have flexibility in how it is encoded, and what we allow. File position of the docreg file is another contingency which shouldn't have any deep binding with the contents or interpretation of any content. If you can address these concerns, then lets do it. Until then, I'm going to beef mine up a little too. -- .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
