[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thanks for your comments.
> >>>>> On Sun, 22 Oct 2000 17:24:24 -0700, David Lawyer <firstname.lastname@example.org> said:
> DL> The problem here is that it's a lot of extra effort for the authors to
> DL> add metadata. I think for most HOWTOs it would be much more
> DL> productive to improve their content and quality. Since the sgmls
> DL> we use allows one to create new tags, I don't think there is any need
> DL> to mention this.
On Sun, Oct 22, 2000 at 10:51:57PM -0200, Jorge Godoy wrote:
> In fact, if we had correctly marked up documents, we could generate
> meta information from it's text. Let's say that it's interesting to
> index all commands used in some document, so that we could group
> documents that use some common commands in a group. This information
> is already there with <command> tags (DocBook).
True, this might be of some interest, but right now one can search for
commands (if they have options) with: grep "sendmail.*-" *
(for the case of the sendmail command). Most commands will use
options. But the Manifesto needs to be kept short and I don't think
that mentioning the metadata problem belongs there. Most commands
have many options and I don't think that the LDP documentation covers
them. Thus most commands shown will be samples that will work in
certain cases. So one needs to read the context of these commands.
> DL> "recommendations" but "requirements" or "conventions". Otherwise
> DL> people will think that we accept any format and not bother to read it.
> And if a document is good but not in 'required' format? Are we going
> to reject it?
Well, up to now we have and a lot of people have been turned off. I
think that handling the formatting for a new author should only take a
small fraction of the time that it takes to write the HOWTO. Thus I
think that it would be a good idea to permit short HOWTOs to be
text-only. I would suggest that these would be called text-HOWTOs or
But since we would like to get out a revised manifesto soon to reflect
a possible new policy on licenses, I suggest that the Manifesto merely
state existing policy on formats. What needs clarification is the
"existing" policy on the Guides. We accepted a few short ones which I
think was a mistake as Guides were intended to be long book-sized
If someone presents a good HOWTO which is not in the required format,
then we would try to find someone to do the conversion. There's a
problem however if the author refuses to maintain it in the required
format. I know of such a case. So we can have a required format but
the "exception" is that it's OK to use another format provided the LDP
(or the author) can find a volunteer to do the conversion. Until it
gets converted, it could be kept in a "wrong_format" directory. This
directory would contain a variety of formats and would only be at the
master site (not at the mirrors).
> I would add:
> (...) check first to see which versions we accept (SGML versions since
> 3.1 and XML versions since 4.1.2 are known to work).
I agree. I wanted to put this info in but I was not able to find it on
> It would make things easier for people writing documents. :-) I also
> suggest that we make a page where we document which versions we accept
> and which versions we recommend.
> DL> You may see what these sgml formats look like by downloading a HOWTO
> DL> (in sgml) from an LDP site. We may accept a HOWTO in just plain text
> DL> if we can find someone to manually convert it to DocBook, etc.
> IMHO, if we say that we 'require' a format, we can't make
> exceptions. That's why I asked about what we're going to do with a
> good document in a format other than the required...
> Maybe the use of 'we strongly suggest' instead of 'require'....
But suppose someone sends in something in a non-standard format and we
can't find anyone to promptly convert it to the required format? Thus
I think we should have required formats with the exception that if we
can find someone to do the conversion to the required format, then
it's OK to use another format. In this case there is no guarantee
that it will be promptly marked up and distributed on our mirrors in
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org