Re: XSL Requirements (was: Microsoft extensions to XSL)

Subject: Re: XSL Requirements (was: Microsoft extensions to XSL)
From: Chris Lilley <chris@xxxxxx>
Date: Thu, 26 Nov 1998 12:50:37 +0100
Sorry for the delay, been travelling and had only sporadic access to
email.

Didier PH Martin wrote:
> 
> > Oren Ben-Kiki wrote:
> >
> > > As Didier PH Martin (mailto:martind@xxxxxxxxxxxxx) correctly
> > pointed out, a
> > > pattern matching language is never sufficient by itself to do general
> > > structural transformations.
> >
> > Right. But then, XSL is not intended as a general structural
> > transformation language. Its a style language that includes the ability
> > to do some transformation as part of the styling step.
> 
> So, if the transformation part is minimal why redo an new language and not
> keep and improve CSS? 

I didn't say the transformation part was minimal. I said it was
specifically focussed.
And, I din't say anywhere not to keep and improve CSS.

> Is it because CSS do not use the <> tagging markup and
> XSL does it?

No, that is a trivial syntactic difference.  A version of CSS written in
XML is trivial to develop; we already have a tool in-house that
validates a CSS stylesheet and optionally writes it out in an XML
syntax. But there is no significant benefit in doing so, and significant
drawback. CSS is already widely used and changing the syntax would break
backwards compatibility.

> > > He's also correct in that it would have been
> > > interesting to start with a procedural language (say,
> > JavaScript) and add
> > > pattern matching facilities to it, instead of starting with a pattern
> > > matching language and adding procedural hooks to it.
> >
> > You mean, like Spice?
> 
> Chris, I tried to do a research on the Web on Spice and I got, you guess
> what? hundreds of links to spice girl sites :-) Do you have any link to a
> site explaining or providing download for Spice? 

Sorry. When I wrote that original mail i did not have web access and was
not sure of the exact URL. Spice was a submission to W3C made by HP. It
basically extends ECMAScript to add pattern matching, units (eg lengths,
colors, etc so you can do things like 50% - 12em + 4px).

The submission is at
  http://www.w3.org/Submission/1998/03/Overview.html
The spec itself is at
  http://www.w3.org/TR/1998/NOTE-spice-19980123.html

> This would help us to understand your analogy to this language. 

Well, it is exactly a procedural language extended to do styling.

> > > The benefits of XSL's approach is that the simple things are less
> > > intimidating then they would have been in a souped-up
> > JavaScript approach.
> >
> > Yes. While a programattic approach always in theory yeilds more power,
> > this is rather like a customer looking to buy a wordprocesso and being
> > sold a C compiler "now you can write whatever you want ... in theory ...
> 
> So, what's your point here? we should stick to style processing only? 

No, my point was that a programatic, procedural approach is
theoretically more powerful but in practicce has ignificant drawbacks.

> And do
> not address the issues of transformation? So why redo an new language if it
> is nearly identical to what CSS provides?

XSL is not "nearly identical" to what CSS provides. CSS has no
transformation capabilities (beyond simple numbering and simple
generated text). CSS does not provide the degree of formatting control
that the XSL requirements document says will eventually be in XSL. And
CSS is already widely implemented, including on small devices and
small-footprint browsers. I expect to see CSS implementations on
handheld devices and consumer electronics appliances such as Web-enabled
televisions. I do not expect to see XSL on that class of devices.

> So, to help us, understand your point of view. Explain why we should redo a
> new style sheet language with minimal transformation capabilities and not
> keep and improve CSS.

Well, actually I would rather not, because that is not what I am
suggesting at all.

XSL does not have minimal transformation capabilities. CSS is being kept
and is being improved. My point was simply that, if someone is looking
for a fully general transformation language, then there are probably
better places to look for one that the tranformation part of a style
labnguage.

--
Chris


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


Current Thread