Mulberry home page

DSSSList Archive

Mulberry Home Page
DSSSL
DSSSList
Archive
Previous by Date
Next by Date
Previous by Thread
Next by Thread
Index by Thread
Index by Date
Index by Subject
Index by Author
Search

Sibling rivalry

From: [email protected] (Jon Bosak)
Date: Sun, 30 Mar 1997 18:10:54 -0800
I'm formatting the latest version of the XML spec and have hit a wall
in handling the productions.

In the old version of the spec, a production had a left hand side and
one or more right hand sides, with each right hand side optionally
followed by a comment, a validity check, or a well-formedness check.

   <!element prod (lhs,(rhs,(com | wfc | vc)?)+)>

This was handled by the following code:

   (element PROD
     (make table
	   (make table-column
		 width: 2pi)
	   (make table-column
		 width: 7pi)
	   (make table-column
		 width: 1.5pi)
	   (make table-column
		 width: 16.5pi)
	   (make table-column
		 width: 9pi)
	   (process-children-trim)))

   (element LHS
     (sosofo-append
      (make table-cell
	    column-number: 1
	    font-weight: 'bold
	    (make paragraph
		  use: para-style
		  start-indent: 0pt
		  font-weight: 'bold
		  (literal
		   (string-append
		    "["
		    (number->string (element-number (ancestor "PROD")))
		    "]"))))
      (make table-cell
	    column-number: 2
	    (make paragraph
		  use: monopara-style
		  font-weight: 'bold
		  (process-children-trim)))
      (make table-cell
	    column-number: 3
	    (make paragraph
		  start-indent: 0pt
		  (literal ":=")))))

   (element RHS
     (make table-cell
	   starts-row?: (not (first-sibling?))
	   column-number: 4
	   n-columns-spanned: (if (absolute-last-sibling?) 2 1)
	   (make paragraph
		 use: monopara-style
		 (process-children-trim))))

   (element COM
     (make table-cell
	   column-number: 5
	   (make paragraph
		 use: para-style
		 font-posture: 'italic
		 start-indent: 0pt
		 (sosofo-append
		  (literal "/* ")
		  (process-children-trim)
		  (literal " */")))))

   (define ($vc-wfc$ vc-or-wfc)
     (make table-cell
	   column-number: 5
	   (make paragraph
		 font-family-name: %title-font-family%
		 font-size: 9pt
		 start-indent: 1pi
		 first-line-start-indent: -1pi
		 (sosofo-append
		  (literal
		   (string-append "[" vc-or-wfc ": "))
		  (process-children-trim)
		  (literal "]")))))

   (element VC ($vc-wfc$ "VC"))
   (element WFC ($vc-wfc$ "WFC"))

Now, however, the editors are allowing multiple comments and/or
validity checks and/or well-formedness checks to follow each RHS:

   <!element prod (lhs,(rhs,(com | wfc | vc)*)+)>

For example:

   <prod><lhs id='NT-Attribute'>Attribute</lhs>
   <rhs><nt def='NT-Name'>Name</nt> <nt def='NT-Eq'>Eq</nt> 
   <nt def='NT-AttValue'>AttValue</nt></rhs>
   <vc name='Attribute Value Type'>Attribute Value Type</vc>
   <wfc name='No External Entities References'>No External Entity 
   References</wfc></prod> 

What I want to do here is to create a new cell only if the COM, VC, or
WFC is the first one following the close of an RHS, and to create just
a paragraph if it's not.  But I don't see any function in the core
query language that will let me do this.

The alternative is to create a new container for the optional stuff
following the RHS, let's call it PINFO:

   <!element prod (lhs,(rhs,(pinfo)*)+)>
   <!element pinfo (com | wfc | vc)+ >

Suddenly life for the stylesheet designer becomes much easier:

   (element PINFO
     (make table-cell
	   column-number: 5
	   (process-children)))

   (element COM
     (make paragraph
	   use: para-style
	   font-posture: 'italic
	   start-indent: 0pt
	   (sosofo-append
	    (literal "/* ")
	    (process-children-trim)
	    (literal " */"))))

   (define ($vc-wfc$ vc-or-wfc)
     (make paragraph
	   font-family-name: %title-font-family%
	   font-size: 9pt
	   start-indent: 1pi
	   first-line-start-indent: -1pi
	   (sosofo-append
	    (literal
	     (string-append "[" vc-or-wfc ": "))
	    (process-children-trim)
	    (literal "]"))))

   (element VC ($vc-wfc$ "VC"))
   (element WFC ($vc-wfc$ "WFC"))

Unfortunately, life for the draft editors suddenly becomes much more
difficult, and it appears that a quick perl hack isn't going to solve
the problem.  (The eds seem to have commented out arbitrary spans
within the productions...)

Does anyone see a stylesheet solution to this problem, or am I going
to have to make the editors unhappy?

(If you see a solution, mail me directly as well as responding to the
list; I subscribe by daily digest, and I'd like to find out sooner
rather than later.)

Jon