Re: alternating tags in a list?

[Joe Kesselman]
> I think that's beyond the scope of XSL per se. To handle odd/even,
> you either need a richer styling language, or you need some way to
> extend XSL.

It's absolutely not beyond the scope of XSL.  This is exactly the kind
of complex formatting that XSL is intended to address.  Speculating
wildly on syntax here, you might have something like

<fo:table>
  <xsl:for-each select="*" group="2">
    <fo:table-row>
      <xsl:for-each select="*">
        <fo:table-cell>
          <xsl:apply-templates/>
        </fo:table-cell>
      </xsl:for-each>
    </fo:table-row>
  </xsl:for-each>
</fo:table>

Another mechanism might be to have some modulo test operator, but I
kind of like the group thing (which I just came up with off the top of
my head, and undoubtedly has serious complications).

The point is that this will be doable; we just haven't figured out teh
best syntax yet.

> Some early versions of XSL did have some ability to invoke a
> procedural language such as ECMAscript, which could provide the
> "state" information for this kind of toggling...

You don't *want* state information.  It makes rendering in a browser
*much* more difficult, and an editor even more so, since you have to
re-render the entire document from the top down after any change.
With side-effect-free languages, you can start the rendering at any
point.

> It occurs to me that what you probably _really_ want is not 2
> columns, but N columns, where N is chosen to suit the width of the
> presentation medium and where the items are flowed from line to line
> to fill out that width. Might be hard to express that in HTML... Do
> the proposed XSL formatting objects allow one to express this kind
> of "flowed grid of size-balanced items"?

This is exactly why XSL has a more complicated formatting model than
CSS.  There's a need to pass constraints for deferred formatting
behavior through to the formatter that requires a more complex set of
formatting objects than a decorated tree.  References to other nodes
and programmatic constraints must also be expressible.  It *could* be
done with a CSS-like syntax (or a Fortran-like syntax, or a LPMUD-like
syntax) but I think that XML seems well-suited.  A formatting
specification is a structured document; just because the semantics of
formatting aren't the usual focus of document analysis efforts doesn't
mean that structured markup isn't the right tool when the focus does
come around.

-Chris
-- 
<!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list