Re: date formats

[David Lawyer <dave@lafn.org>]

On Thu, Dec 07, 2000 at 12:31:01PM -0500, David Merrill wrote:
> On Fri, Dec 08, 2000 at 01:21:26AM +0800, Gregory Leblanc wrote:
> > > A recommendation is outlined below; I've extended this as to what
> > > I think would comprise a good/valid MINIMUM set of elements for
> > > a header area for LDP documents:
> > 
> > 
> > Couple of things I'd like to harp on are below.
> > 
> > > ---
> > > 
> > > if linuxdoc:
> > > 
> > >    <title>title of HOWTO, include "HOWTO" or "mini HOWTO"</title>

In linuxdoc there should be no optional end tag </title> to reduce
keystrokes.

> > 
> > 
> > <title>Title of HOWTO, include "HOWTO"</title>
> 
> I agree. Did we ever come to a really final decision on whether or not
> mini is going away? I'm *really*, ***REALLY*** not trying to restart a
> flamefest here; I don't remember. I'll abide by the majority opinion
> once I know what the hell it is. :-)
> 
> > >    <revhistory>
> > >      <revision>
> > >        <revnumber>v2.0</revnumber>
> > >        <date>DD MMM YYYY</date>
> > >      </revision>

Talking about the revision number not inside a <revhistory>
environment: 

What will this be for linuxdoc that has no <revision> tag AFAIK?

I suppose it could be 
<date>v2.0, YYYY MM DD

Then it will need to be automatically conveted to docbook which will
take a little programming work.
Or we could add a <rev> tag to linuxdoc.  Or it might be best to put
both revision and date after the <date> tag in docbook so as to keep
it the same as linuxdoc.

> > > 
> > >      <!-- Additional, *earlier* revision histories go here -->
> > 
> > 
> > I've taken to NOT keeping a complete revision history, but instead just
> > the last few <revision>s.  The complete log is stored in CVS, so I can
> > see the entire history. 
> 
> This seems reasonable to me. The LAG is on about its tenth revision
> already.
> 
> Maybe we should recommend that the revision hierarchy be occasionally
> pruned? Leave major (X.0) revisions and remove .X revisions at some
> point.
> 
> > > More tags *could* be used (<othercredit>, <titleabbrev>, <orgname>,
> > > <copyright>, <authorinitials>, <revremark>, etc.) and perhaps
> > > more should be used, but I see this as being a *minimum*  set of
> > > tags that constitute a valid header area.
> > > 
> > > Please provide comments. As David says, we should get these
> > > guidelines into the style section of the LAG.
> > 
> > 
> > Perhaps we could add the rest of the tags inside of comments <!-- -->,
> > so that they're available, but authors don't feel obligated to use all
> > of those tags?
> 
> I see this as a question of which path we make the "default" and
> therefore the easiest for authors. I think your suggestion makes
> leaving those tags out the path of least resistance, and mine makes
> including them the path of least resistance. IMHO, including them
> should be easier than taking them out. We want them to be used. Of
> course, this depends somewhat on where you draw the line. Tags that
> are really rarely used could go in comments, while the rest do not.
> 
> -- 
> Dr. David C. Merrill                     http://www.lupercalia.net
> Linux Documentation Project                dmerrill@lupercalia.net
> Collection Editor & Coordinator            http://www.linuxdoc.org
> 
> I used to be a rebel in my youth.
> 
> This cause... that cause... (chuckle) I backed 'em ALL!  But I learned.
> Rebellion is simply a device used by the immature to hide from his own
> problems.  So I lost interest in politics.  Now when I feel aroused by
> a civil rights case or a passport hearing... I realize it's just a device.
> I go to my analyst and we work it out.  You have no idea how much better
> I feel these days.
> 		-- J. Feiffer
> 
> 
> --  
> To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> 
			David Lawyer


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org