[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplified DocBook
David et al:
> I think that what we ask people to use should be far simpler than
> HTML.
Then they should use text, or a WYSIWYG/WYSIWYM editor.
> I've just looked at one of my HOWTOs in LinuxDoc to see how many
> different tags I use. The header uses 6 tags but they never change.
> The body only uses 11 different tags with 3 attributes. Of these 11
> tags, 3 are almost the same: <sect>, <sect1>, and <sect2>.
This e-mail, discounting any punctuation, only uses 26 letters.
Furthermore it is sent via a protocol, SMTP, that only uses ASCII
encoded text both for command and transmission. The sheer number of tags
means little when taken out of context.
> LinuxDoc actually has many more tags than I use. But another
> advantage is that tags are short and the <p> tag for paragraph is
> optional (double spacing means the same as <p>). This means that much
> of the doc when displayed on a 25 row terminal shows only plain text
> (no tags are seen). Can DocBook do this?
That is an invalid point. What I think you are saying is that you
believe that short tags, and what amounts to tag abbreviation, is a good
thing. However you then add context and disregard the purpose of DocBook
which, I contend, invalidates your argue on a logical level.
Any document written in DocBook SGML or XML (with the DTD) can be
guaranteed to be valid using a validating parser such as XP or nsgmls.
SGML and XML are both markup languages; the DocBook DTDs define a valid
document. That LinuxDoc has a DTD which is more lenient than DocBook XML
is rather beside the point you are attempting to make.
If we were to prescribe DocBook XML as the markup language, I would
argue that XML's insistence on proper form would assist everyone in the
long run.
> Also, LinuxDoc doesn't usually need end tags. It's so obvious where
> the tagged region ends that I never really thought about it until
> someone mentioned that there is an implied end tag. Can DocBook do
> this?
See my arguments above.
> Then LinuxDoc sometimes uses nested tags like a <Para> tag
> inside an <ListItem> whereas in LinuxDoc no <p> tag is needed inside of
> a <item> "element".
I think you've mistyped at least one of the LinuxDoc's here.
> I rather doubt if a simplified version of DocBook can be made to look
> like LinuxDoc. If it could, then we could abolish LinuxDoc and call
> it mini-DocBook. So one question is: Can something more simple than
> LinuxDoc be devised?
The alphabet has already been invented, and I might suggest that we seem
to agree that some kind of human language is the go. Text is already
there.
> Should additional tags be created for LinuxDoc?
Which would make it become like the "lesser DocBook DTD"...
The reasons for having people create a validatable (not just well
formed) document to submit to any publisher such as the LDP should go
without saying. Whilst I do not intend to use LinuxDoc myself I am
satisfied that it is a reasonable, easy-to-use and not too difficult to
support DTD or other entity. Other people may choose to use DocBook SGML
or XML for their own purposes; I use it in my professional work and find
it natural to use when writing or submitting my "voluntary" documents.
Conducting a debate centered around "LinuxDoc allows you to use [insert
something here] whereas DocBook (because it's an XML or SGML DTD) does
not" doesn't really prove anything given that LinuxDoc and DocBook are
totally different items and cannot be so easily compared. The question
we should address is "what benefits do LinuxDoc and DocBook display;
given these sets of benefits is it worth supporting one, both or trying
to find another alternative...."
Arguing about the form of these documents is getting tiresome. Putting
it bluntly, if someone produces a very good document but it's formatted
in text, Word or some other strange format then someone may find the
time to translate it into something else (LinuxDoc, DocBook XML or
whatever).
DL
--
Words are easy; words are cheap
Much cheaper than our priceless land
But promises can disappear
Just like promises in the sand...
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]