OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK-APPS: Inquiry on inlines vs. sections of similar nature


Norman Walsh writes:
 > / Bernd Kreimeier <bk@lokigames.com> was heard to say:
 > | E.g. there seems no way to mark every occurence of 
 > | whateverFunc in a way that would (with proper stylesheet)
 > | render them identically. In other words, there is no
 > | match for e.g. <programlisting> or <funcname> that works
 > | inlined in regular text. You can use EnvVar to acocmplish
 > | matching appearance, but that's exactly the kind of abuse 
 > | you want to avoid. In reversal, a matching EnvSynopsis
 > | is absent as well.
 > 
 > I don't think I follow. You have a thing, a functionName() let's say,
 > and you want to render it inline sometimes and in a block at other
 > times and you want the appeance to be the same?

It's more than that. Say you have a blockquote, an entire
paragraph or two, that you dissect word by word, and
sentence by sentence, in the surrounding section. So there
will be bits and pieces of the blockquote littered throughout
the preceeding and following text. Having similar appearance
for the blockquote in its entirety and for any repeated
fragment is one possible way to emphasize the connection.
Another one (in a hypertext) is to turn every occurence of
a partial quote into a link to the full quote.

Let's say you have a FuncSynopsis on functA(). Now, in a
FuncSynopsis for FuncB() somewhere else it might be natural
to discuss and explain the function in terms like

  "FuncB() is always to be used in combination with FuncA(),
  but is mutually exclusive with use of FuncC()."

Again, in printed text an identical appearance of
repeated occurence of FuncX() might be a good tool.
In hypertext, a direct link to the respective synopsis
is even better. Let's say somewhere else in the book
you discuss an example/programlisting at great length,
step by step - every mention of funcA() and funcB()
should be marked in a way that points (visually or
hyperlinked) to the synopsis.

In the inverse: the EnvVar element provides the inline,
but there does not seem to be a matching EnvVarSynopsis.

There is an underlying pattern here. When I tried to
overhaul the Linuxdoc DTD (ages ago), I called it a
glossary+keyword combination. Maybe you can call it
"pars pro toto" - a writer using a shorthand for an
entire part of the document. Somewhere in the text there 
will be a definition/instantiation for an (abstract)
entity: call it synopsis, quote, example. All over the
surrounding document there will be mentions and references 
to this entity - so shorthand has become a keyword (or,
in your DTD, a GlossTerm?).

Linuxdoc DTD relied on an ASP based backend (single pass
textual replacement), so elements were really simplistic, 
somwhat like

   paragraph           inline

   <quote>              <q>                 italic
   <code>               <c>                 tt
   <keyword>            <k>                 bold

I also made some attempts to make these elements appear 
in the Index: e.g. that the paragraph instance would be 
marked as the main reference, and every other occurence 
could be listed as well, depending on an adjustable 
visibility attribute (vis=0|..|9).

Anyway, I found the "pars pro toto" relationship to be
a recurring theme in the documents I wrote, and would
like to know how to do appropriate markup DocBook. 
What I am looking for seems to be a GlossTerm
equivalent for elements like BlockQuote, FuncSynopsis,
as well as an equivalent to FuncSynopsis for inline
elements like EnvVar. Sounds reasonable? Maybe I should
wrap my brain around how you architected Glossary.

                                         b.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC