Re: node lists

[Norman Walsh <ndw@xxxxxxxxxx>]

/ "Joerg F. Wittenberger" <Joerg.Wittenberger@xxxxxxxxx> was heard to say:
[...]
| <!element hld - - (intro, extinterface, dataobjects) >
| <!element extinterface - o (dataobjects, userinterface, commands,
| messages, files)>
| 
| All of them have an internal structure like "section" from docbook,
| except that they don't have a title etc. (this shall be generated from
| the style sheets).  Actually a document like:
| 
| <hld>
| <intro>
| <para>bla bla</para>
| <extinterface>
| <dataobjects>
| <para>blub</para>
| 
| Should be processed like this docbook equivalent:
| <book>
| <chapter><title>hld</title>
| <section id="hld.intro"><title>Introduction</title>
| <para>bla bla.</para>
| </section>
| <section id="hld.extinterfaces>><title>External Interfaces</title>
| <section id="hld.extinterfaces.dataobjects>
|  <title>Dataobjects</title>
| <para>blub</para>
| </section>
| </section>
| </chapter>
| </book>

One possibility would be a pre-process that does that transformation,
but ... 

| The problem is, that those section are hard to enumerate.  (Even worse
| we have an attibute, which supresses the section from the output -
| hence it is not supposed to be counted.  But that's a minor problem.)

Take a look at component-number in dbcommon.dsl.  This function handles
numbering of components which can be a little complex.  For example,
CHAPTERs are numbered sequentially in a book, even when they occur
grouped in PARTs.

| Additionaly things like extinterfaces should be subdoc's if possible
| at all.

Uh, I think that would make the numbering nearly impossible.

| The only solution I found until now, which allows me to enumerate the
| section properly looks like the following.  I'm not satisfied with it,
| because I want to use as much as possible from the docbook style
| sheets, but I am using too few.  At least the cross referencing and
| the generated html navigation elements are something I definatly don't
| want to loose.  But even that and the diversion into the html files
| dosn't work.

There's a few things you probably have to change to make that work.
As a first approximation, change 

(define (chunk-element-list)
  (list (normalize "preface")
	(normalize "chapter")
	(normalize "appendix") 
	(normalize "article")
	(normalize "glossary")
	(normalize "bibliography")
	(normalize "index")
	(normalize "colophon")
	(normalize "setindex")
	(normalize "reference")
	(normalize "refentry")
	(normalize "part")
	(normalize "sect1") 
	(normalize "book") ;; just in case nothing else matches...
	(normalize "set")  ;; sets are definitely chunks...
	))

so that it contains the new elements that you want to chunk on.
You'll also have to add some things to dbl10n.dsl and the language
of your choice to handle the generated text for XREFs to those elements.

(This isn't the XREF problem you described in mail to the DocBook list,
is it?  If so, I now understand completely why XREFs didn't work ;-/)

| If I had something like (make-node children-node-list), which would
| create a fresh node list with the specified children, which in turn I
| could process as if I had read it from a file, that would be most of
| the deal.  I could say:
| 
| (element intro
|  (process-node-list (make-node gi: section
|                       (node-list 
|                        (make-node gi: title "Introduction")
|                        (children (current-node))))))

Well, I'm not sure exactly what you're after, but you could certainly
write a function that collects all the children of INTRO and builds
a node list that contains only the ones you want enumerated. Then you
could walk down that node list counting them.

If there aren't too many nodes to look at, you could even have your
construction rule for the elements inside INTRO do this calculation
each time, and simply find themselves on the list.

                                        Cheers,
                                          norm
-- 
Norman Walsh <ndw@xxxxxxxxxx>      | Everything is temporary.
http://nwalsh.com/                 | 


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist