Am 16.01.2006 um 17:12 schrieb Roman Joost:
On Fri, Jan 13, 2006 at 08:02:55PM +0100, Axel Wernicke wrote:Sounds good for me, I propose to include additionally 'book, part, chapter, preface,We include revision, date and author for only the *last revision*. This is automatically filled in by CVS, once we added the code example listedbelow. It'll look like this (using sect1 as an example here): <sect1info role="cvs"> <revhistory> <revision> <revnumber>$Revision$</revnumber> <date>$Date$</date> <authorinitials>romanofski</authorinitials> <revremark></revremark> </revision> </revhistory> </sect1info>OK, this directly leads to the question which elements we should to this for. Since there is no such thing in docbook as "pages", we have to decide for a level of sect I'd suppose. Howabout doing it for sect1 and sect2 elements?index, appendix'. So, the list grows to: 'book, part, chapter, preface, index, appendix, sect1, sect2'
[x] agreed
By the way, it's valid not to have a revremark element.Oh, that would be nice. Are you sure? I tested it and it gave me an error, but could have been my fault. Haven't investigated more ...
well, double checked that and - it seems indeed to be valid--> revision ::= (revnumber,date, (author|authorinitials)*, (revremark|revdescription)?)
Its OK, so lets stick to the little xml comments for a short description of the most recent changes on content and use the revision elements for kind of a cvs revision mark.The revremark element is left blank. I'm not sure if we should keep theversion history via comments and put a remark about the last changes in the revision tag.So there we have the second important issue. As far as I see the usage of revhistory as proposed here has not the power to replace the remarks done for authoring in the head of eachfile.I proposed to use only the last revision, because the last discussion turned out, that most authors don't want to write the each change in arevhistory element. I'm fine with that. Keeping the comments as a small changelog for each article isn't that verbose as it would be, if we useXML.
Lets say we have a file containing en and a fr translation. Content for booth is ages old. Then somebody gratefully updates the en part and whops, the whole thing gets a new recent and shiny cvs revision. Also for the fr part which was not touched for ages. Anyway to have some sort of revision and date is better than nothing. So lets go for it.This is because your proposal gives the reader of the manual a date which he knows then is the least age of the content. Additionally he gets the revision - whatever that will tellIs this really important? It is more important for the reader IMO, that he reads an up-to-date document and not the first draft of one article.him.It's neither language specific, nor does it contain the information about what changed in thecontent of a file at a specific time.Therefore having a revision and a date is much more interesting than what was changed in the last revision. Btw. why do you want to provide language specific revision logs?
So, whether we extend the revhistory to something like: [...] example with more than one revision elements which is pretty verbose, but can replace the comments with something machine readable.Hm.. no... let us keep the comments...
well, it was just an idea. I can live pretty well with the comments. Greetings and thanks for all the efforts you put into this! lexA
Greetings, -- Roman Joost www: http://www.romanofski.de email: romanofski@xxxxxxxx _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
--- Live is like a chocolate box, you never know what you wanna get... GPG Signatur auf http://wernicke-online.net/Impressum/ prüfen
Attachment:
PGP.sig
Description: Signierter Teil der Nachricht
_______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
