Am 29.07.98 schrieb apharris # burrito.onshore.com ... Moin Adam!
APH> the system was doing mandatory link integrity; so expressing that APH> you're a relation of a file which no longer is actually somewhere else APH> is not a big difficulty for me. You seem to think it's an absolute APH> nightmare situation whereas I don't. Ok, you see the problem. Why shouldn#t we solve this problem? My prosposal is a nice solution without any problems. So why shouldn#t we use it? I#m using my file format proposal for my latest alpha version of dhelp_parse 0.4.x and the results are not bad :). APH> > you change the identifiers. APH> That's the risk with URLs! But we#re not using URLs for local files! APH> I'm willing to live with that, until we APH> have a URN system, or better yet, something based on XLink (drool APH> slobber). Again, I#m not interested in using a URN system, because it#s 100% useless. APH> The problem I have with your system is that it locks out URNs, URCs, APH> and other potentially useful ways (ISBNs) of identifying resources. No, that#s not true. I#m using the Identifier tag as an identifier for a docreg element and not for a document. For example you could have to versions (PS, HTML) of one book. And so we can#t use the ISBN number as identifier. And you could of course use URNs for the "File: " line. Maybe we should use another name for "File: " like "URL: ". APH> However, I don't want to appear to be completely oblivious to your APH> suggestion. How about I leave the syntax of the "Identifier" the same APH> and add as well an optional "Debian-identifier" element for those who APH> want to define persistent IDs. The in the "Relation" element or APH> whatever you could use the proprietary URL APH> "debian-id:<package>/<identifier>" syntax to notate this. This way APH> the whole thing is optional.... Right and that is bad. I#m working on a translation document, I have to ask the maintainer of the original document to release a new version with this debian-identifier. APH> Would this sort of thing suffice? No, I don#t see your problem with my solution. The unique identifier shouldn#t be optional. I don#t understand, why you like using filenames as identifier. This is not required by the DC "standard". The identifier should be unique and pseudo persitent in the docreg system. That#s why we should use your debian-id als "Identifier: ". APH> > Why? They have to be unique and the package maintainer shouldn#t change APH> > the IDs of documents. APH> How do you propose we *enforce* this? We can't. That's another We don#t enforce but propose it. The maintainer should use something like for example "<package>/<doc filename>" or "<package>/<title>". Where#s the problem? APH> reason why I don't like your scheme; I feel my comprimise solution is APH> ok though. I don#t see any differences for this topic. APH> * no need to maintain global namespace of uniq ids (my comprimise of APH> "debian-id:<package>/<identifier>" solves this) Sorry, but you#re 100% wrong :). I#ve suggested to use <package><free name> as identifier. So where#s the need to maintain a global namespace of uniq ids? I don#t see that. But with your solution you#ve to maintain it! If to packages add the same URL (for example to www.debian.org) you have got a problem! APH> Surrogate, globally unique keys are not an idea I want to foist on the APH> world, especailly w/o a strong centralized mechnanism. My comprimise APH> is to allow a light-weight translation system intead, and keep it APH> optional. Sorry, but I don#t understand your arguments. For the package maintainers there#s no big difference between both proposal. But my proposal offers some additional advantages. APH> > What should I see above? I#ve proposed a unique ID and a file tag. I#ve APH> > never proposed a URN system for documents. APH> Why not? You should! No, we could talk about URNs, if there#s support in the WWW browsers. But using CGI-scripts or apache#s rewrite module is useless for a local system. APH> > Your proposal uses the identifier as URL/file. And this is a real bad APH> > idea and this breaks the DC idea. APH> Not at all. The DC system makes no claims in the persistance of the APH> identifier, and requires no such persistance (though it's always APH> nice). That#s right and I think that this is a bug. A lot of people uses URLs as identifier, but this is 100% nonsense. APH> BTW, you know that DC is on the IETF standards track now, right? I don#t know. Is that important? Again, my proposal doesn#t break the DC standard. APH> > P.S.: I#ve started to develop dhelp 0.4.x APH> Excellent. Please let us know any flaws in the system your APH> implementation work leads to. At the moment there#re no problems, but I#m using my proposal (File: (relative), Identifier:, docreg in /usr/doc). APH> I'm starting the parsers already too. Fine. APH> Sorry they are all in perl still since my time is so short. Marco I#ve got the same problem :). There#re some nice exams this month and next month I#ll move to Manchester, UK :). APH> thinks they *must* be in C. Any porters volunteer? Otherwise it APH> probably won't happen for a while. You could of course use my parser. It#s only one small function. At the moment I#ve got real problems with libdb :(. Its documentation is really bad. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED] http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
