I agree with most of what you say here.  I think there needs to be an
abstract set of flow objects that is well defined for XSL.  However, I also
think that many output formats will need flow objects which are not defined
in a generic XSL specification.  There needs to be some way to take
advantage of the format specific capabilities.

I have been building an RTF implementation of the XSL processor.  There are
some RTF specific things which I want to be able to include.  For example,
RTF has a Table of Contents element.  I could try to build this up in XSL
but I would be sacrificing the functionality of the native element.  The
native RTF Table of Contents can be updated if the document changes.  I can
also change the style of the TOC after the document has been generated.
RTF editors can expose other functionality like allowing the user to
navigate by clicking on a line in the TOC.

If I build a TOC line-by-line by using XSL core flow objects I would not be
able to gain access to the native formats full cababilities.  An Aural
output format is a good example .  I'm sure that there would be many flow
objects needed for this format that are not in the core set.

I think we need to somehow logically seperate the XSL processing of the
rules from the flow object to output format translation.

-Mark

<<<I think it would be appropriate to replace flow classes <DIV> and <SPAN>
with
their corresponding names in the 'display' property: <block> and <inline>.
This would help alleviate the confusion the existing tags have created.  To
would also help define a future direction for XSL with respect to CSS flow
objects (that being the inclusion of new flow objects <run-in>, <compact>,
and
maybe most of the table related display options; 'marker', 'list-item', and
'none' are redundant within the XSL syntax).
...>>>



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