[DOC-SIG] Library reference manual debate
Case Roole
cjr@bound.xs4all.nl
Sun, 16 Nov 1997 10:08:13 +0000 (WET)
Paul Prescod wrote:
>
> Case Roole wrote:
> > Just wondering: for HTML generation I use "megatags", non-HTML tags in
> > documents that are otherwise HTML. An SGML parser (derived from the one
> > in sgmllib) lets pure HTML pass, but fetches and processes the data
> > embedded in these megatags (example below). This is decidedly not pure
> > SGML or pure HTML, but the *code is extremely readable*. Is this what
> > everybody is using the SGMLParser for, is it irrelevant for the matter
> > discussed here, or is this a good idea?
>
> SGML was explicitly designed to allow this and has features to do this
> sort of thing for you. A full SGML parser can interpret your "=" symbol
> and even your newlines as tags. This is very convenient for typists. I
> think that for novice users it will probably be quite confusing,
> however, because people are used to all SGML markup being in clearly
> marked tags, not in ordinary-looking characters. Also to parse something
> like this in Python we would either have to complicate sgmllib or
> introduce another layer of parsing.
Shortly:
1. What's wrong with introducing another layer of parsing?
2. I have reason to doubt that a mixed format will be confusing.
Extended:
ad 1.) I haven't looked at SGML for years and forgot much of what I once
learned. I take it on your word that a full SGML parser can interpret
all kinds of non '<'..'>' embedded tokens. If we are using a python
WYSIWYG editor based on a DTD for these docs, the proposed mixed format
would require a complication of sgmllib.
I have the impression that the consensus is that we are to use a
non-wysiwyg editor for the time being, so this doesn't apply.
Thus I end up with the other option, which, fortunately, is what I was
thinking of in the first place: introduce another layer of parsing.
I can think of no other penalty for this than that the computer works
a little longer when doing the one-time job of converting the dirty-
but-readable manual format into something standard tools can further
process.
ad 2.) I doubt the validity of your assessment of the degree to which a
mixed format is "confusing".
"This is very convenient for typists." -- Indeed, that's what Guido was
referring to when he started this thread.
"I think that for novice users it will probably be quite confusing,
however, because people are used to all SGML markup being in clearly
marked tags, not in ordinary-looking characters." -- Given that we are
talking about the python documentation here, I don't see who those
"novice users" are, who are "used to all SGML markup being in clearly
marked tags".
We all get along with not closing python statements with ';' and not
enclosing blocks in '{'..'}'. I guess that those who write the
documentation will catch up quickly if the documentation is to be written
in some mixed format that looks good, even if it would take an advanced
SGML parser to interpret it in a single step.
cjr
--
Case Roole <cjr@bound.xs4all.nl>
_______________
DOC-SIG - SIG for the Python Documentation Project
send messages to: doc-sig@python.org
administrivia to: doc-sig-request@python.org
_______________