[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: CSS for transformation


Subject: Re: CSS for transformation
From: "Philippe Le Hégaret" <Philippe.Le_Hegaret@xxxxxxxxxxxxxxx>
Date: Thu, 08 Oct 1998 11:45:29 +0200

Paul Prescod wrote:
> I didn't claim it was a big problem. I didn't claim that the CSS model
> could never have new functionality added. The truth is that the XSL model
> will be largely based on the CSS model. It will essentially be the
> formatting part of CSS3.
> 
> > And if people wants an X, it's very easy to create the XCSS.
> 
> Sure, but why?
  Because I don't want to implement two differents style models
in my application, one for CSS and one for XSL. I don't like
the word "largely" or the word "essentially".

> >   XSL wants to poorly transform XML documents into another
> > XML document and it works (not well, but it works).
> 
> I've used more than a dozen transformation languages, and XSL is the most
> well thought-out of the bunch. It is an *excellent* transformation
> language, and it works beautifully.
  No, for me it's not. I don't want to support an undocumented
post processor in my XSL. I don't want to support a specific
XSL engine just because this is the only one post processor
for my output format.
  

> >   XSL can't transform an XML document into an unknown format.
> 
> Neither can CSS. Anyhow, I call a transformation into a completely
> different format a "conversion" and I think that it is the job of a
> different piece of software.
  CSS is not for conversion, only for the style. And "a different
piece of software" is too general for me.

> > I know, you
> > could add a namespace and do a post-processor, but is it the good solution ?
> 
> Yes.
  Not agree with this. It's an another way to say : "You can't do the
conversion with XSL, so write a program for this.". XSL can't define
a namespace for all existing format.

> > And, if it's not the goal of XSL, should we work on an another solution ?
> 
> Only if you can point out something concrete that is wrong with the
> current solution.
  see above.

> Using xsl:if and xsl:for-each is not programming, and XSL is not a
> programming language. Conditionals and iteration are not enough to make
> something into a programming language.
  You can program a lot of things with only an if, a for and a when. Look
this stupid example :

<xsl:template match="namelist/name">
  <xsl:process-children/>
  <xsl:if test=".[not-last-of-type()]">
     <xsl:choose>
        <xsl:when test='ancestor(orderedlist/orderedlist)'>
          <xsl:number format="i"/>
        </xsl:when>
        <xsl:when test='ancestor(orderedlist)'>
          <xsl:number format="a"/>
        </xsl:when>
        <xsl:otherwise>
          <xsl:number format="1"/>
          <xsl:for-each select="item">
            <xsl:process-children/>
          </xsl:for-each>
        </xsl:otherwise>
      </xsl:choose>
  </xsl:if>
</xsl:template>


> You're looking for a different solution than XSL because XSL doesn't do
> everything you want *yet* (though it is intended to eventually?). What
> makes you think that your different solution would be available before XSL
> was completed?
  Nothing. But I don't think for the moment that XSL will be the solution. It's
just a way to find it.

Philippe.


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



Current Thread
Keywords