|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: More XSL Discussion
[Paul Prescod]
>
>>I strongly suspect that XSL will require this balancing *anyhow*. XSL
>>flow objects are not HTML *code*, they are HTML *elements*. I do not
>>think it makes sense to create half an element...
A big part of doing it the XSL/DSSSL way (no half elements) is to give the
render
a dig out in knowing when a flow-object is finished to that it can
do on-the-fly, progressive rendering. This is going to be a hugely important
aspect of XSL enabled browsers.
OTOH, emitting half an element is both convenient and natural when
targeting an output format that does not need to be interpreted whilst
partially complete.
I think it is noteworthy that a lot of the XML parser interface activity
naturally facilitates the "half an element" approach thanks to
event based design. I suspect developers who get their head around SAX
and use it to spit out piecemeal HTML are going to find XSL requires
a mind shift!
I think there is value in having the very natural feeling declarative
context specification stuff from XSL without the flow object stuff.
In fact, I have had cause recently to use it in that way. Basically
using XSL to deal with all the context stuff and println() for the
entire output.
Being able to do this:
<element type = "chapter">
<element type = "sect1">
<target-element type = "title">
println (...)
Sure beats this for legibility, speed of development, ease of modification etc.:
// pseudo code
start_title() {
if (parent == sect1 and parent.parent==chapter)
println (...)
}
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|

Cart








