Re: Leventhal's challenge misses the point

Subject: Re: Leventhal's challenge misses the point
From: "Guy Murphy" <guy-murphy@xxxxxxxxxxxxx>
Date: Sat, 29 May 1999 20:54:37 +0100
Hi Didier.

I agree on this point, XSL does not look at it's best when engaged in
procedural tasks. It is for this reason that I was initialy in favour of the
infamous <xsl:script>, and why I need to play more with the new mechanisms
for introducing hooks to other languages into XSL.

However, I take well the point that Paul Prescod raises regarding what may
be lost in allowing side effect possibilities into XSL, so now I find myself
sitting on the fence with regard to this issue.

In terms of allowing factoring within XSL, I think persuits to date have
been influenced by procedural thinking. I understand that we can now use
named templates as macros, and this is a good thing. What I would also like
to see is a mechanism for defining FOs out of existsing FOs. This would take
some of the preasure off the XSL-WG on getting it "right" first time, and
allow observation of FO usage for incorporation into future versions of XSL.

::shrug:: maybe something like...

<xsl:fo name="menu-item"> spec...
    <xsl:value /> spec...

If we were going to HTML this might allow...

    <xsl:fo name="menu-item">
            <td><xsl:value /></td>

...and from XSLT we could use the above as...

    <xsl:template match="//navigation/item">
            <xsl:value-of select="." />

Yes we could do this from the macro paradigm, but they aren't the same
thing, and in a descriptive/declarative language *how* you describe things
is important.

I believe that such a mechanism will serve not only as a useful way to
factor and abstract, but invaluable when XSL must eventualy make the
transition from producing HTML in the borwser to producing FOs. This isn't
as much of an issue in the print world, but will I believe be a crucial
transition in the browser world. It will also make supporting legacy systems
easier, in that it povides a means to map XSL FOs to legacy formatting.

We might also imagine a lib of FOs being produced for an application to be
used by the apps stylesheets.

As a side benefit, if one is concerned with the semantics represented by XSL
FOs one can map to a prefered semantic. The FOs at present are very document
and print orientated at present, which I accept as par for the course as XSL
progresses, but such a mechanism migh tprove helpful for We designers.

Also, while I think about it (thinking out loud really), might not such a
mechanism introduce polymorphism to FO which might be useful for
accessability and other media formats?...

<xsl:fo name="block">
        <xsl:value />

Which would allow mapping to other formats without having to resort to
production and maintianance of diverging stylesheets?

All this is off the top of my head so might well not stand up to scrutiny,
and I confess to not being as familiar with the formatting side of the spec
as I should be. Maybe I need to spend some time with the InDelv Browser.

XSL is supposed to be extensible, and I'd like to see a little more
extensibility in the FO department. In this way we might be able to avoid
recource to non-declarative techniques.



----- Original Message -----
> bad points about XSL:
> - some produced Ural constructs included in XSL do not fit well in a
> declarative language
> In fact, as long as XSL is declarative, it does a very good job and has a
> major advantage to seamlessly integrate with XML or HTML constructs. When
> XSL tries to be procedural it fail compared to the clarity of other
> procedural language. the inverse is also true. When procedural languages
> to be declarative (within the constraint of keeping only procedural
> constructs) it also do not fit well. I have not seen yet a language mixing
> both procedural and declarative constructs elegantly.
> regards
> Didier PH Martin
> mailto:martind@xxxxxxxxxxxxx
>  XSL-List info and archive:

 XSL-List info and archive:

Current Thread