[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Processing instruction guidelines

• To: Elliotte Rusty Harold <elharo@m...>
• Subject: Re: Processing instruction guidelines
• From: Norman Walsh <ndw@n...>
• Date: Fri, 31 Jan 2003 12:30:47 -0500
• Cc: xml-dev@l...
• In-reply-to: <p04330104ba605c45f7b9@[192.168.254.4]> (Elliotte RustyHarold's message of "Fri, 31 Jan 2003 12:09:35 -0500")
• References: <37198796063.20030123160719@j...><87znpqr5wj.fsf@n...> <p04330104ba605c45f7b9@[192.168.254.4]>
• User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.1 (i686-pc-linux-gnu)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Elliotte Rusty Harold <elharo@m...> was heard to say:
| At 9:14 AM -0500 1/24/03, Norman Walsh wrote:
|
|>- - Provide hints for line numbering of verbatim environments
|
| What hints? Start number? If so, couldn't this be better handled by an
| attribute? It seems like a fairly fundamental aspect of a verbatim
| environment?

I was thinking, in particular, of the line-numbering frequency. Number
every fifth line, for example.

|>- - Control the style of function synopses (K&R or ANSI)
|
| That feels like a stylesheet parameter to me, or maybe the
| funcsynopsis element should have a language attribute that allowed you
| to select ANSI C, K&R C, Java, C++, Objective C, etc.

The PI *is* a stylesheet parameter. Of sorts, anyway. In the
particular case of the DocBook stylesheets, there is a parameter to
set the global style; the PI just lets you override it on a
per-synopsis basis.

|>- - Control presentation of some lists as blocks or tables
|>- - Specify rotation for table cells
|>- - Specify background color for table cells
|
| All three of these could be controlled by stylesheet options or
| separate stylesheets for separate effects. I'm not sure that would be
| convenient enough but it could be done. It seems to me that this mixes
| presentation with content. Putting the presentation info into
| processing instructions instead of attributes really doesn't change
| that. But maybe you do need to do this. I'm not sure.

These options all sit in the gray area between pure semantic markup
and presentation details. They spring into existence for two primary
reasons:

1. A need is identified and must be addressed faster than the schema
   can be changed. So, the DocBook TC might someday add attributes to
   programlisting to further control aspects of line numbering. But if
   you want every fifth line numbered on this listing and every other
   line on that listing, you need something you can stick in there
   *today* that doesn't interfere with the validity of the source.

2. A need is identified that really just patches a shortcoming in the
   presentation system. In the case of lists presented as blocks or
   tables, a really smart presentation system might have some way of
   determining which presentation would be more aesthetically pleasing
   and choosing that one automatically.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@n...> | More men become good through practice
http://nwalsh.com/            | than through nature.--Democritus of
                              | Abdera
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+OrLHOyltUcwYWjsRAhsAAKCDRjKNAFH5zW9Jkq8RlLxje0IqRwCfSaOp
DbxNPXxs8WjhW6/e51vTkfA=
=mwk7
-----END PGP SIGNATURE-----

• References:
  • Processing instruction guidelines
    • From: Jeni Tennison <jeni@j...>
  • Re: Processing instruction guidelines
    • From: Norman Walsh <ndw@n...>
  • Re: Processing instruction guidelines
    • From: Elliotte Rusty Harold <elharo@m...>

• Prev by Date: Questions on Initializing Parameters for XSL
• Next by Date: Re: Processing instruction guidelines
• Previous by thread: Re: Processing instruction guidelines
• Next by thread: Re: Processing instruction guidelines
• Index(es):
  • Date
  • Thread