RE: Style vs. Transformation

Subject: RE: Style vs. Transformation
From: Tony Stewart <tony.stewart@xxxxxxxxxx>
Date: Thu, 5 Mar 1998 14:38:56 -0000
Paul Prescod and Jani Jaakkola wrote:

"> Probably, an independent transformation step seems overkill in a
_Style_ 
> language. But why couldn't you expect requirements for modifying the
document's
> structure during processing ? Do you really believe that the frequent
transformation 
> needs among SGML users (evolution of DTDs, authoring vs. repository
DTDs, ...)
> will all of a sudden disappear because they're using a fixed concrete
syntax ?

"The need for transformation language won't go away for sure.
The point is, that the style language with SGML flow objects could
also be the answer to transformation problems."

As I understand it (and I may well be wrong), the flow objects won't let
us get back to the document structure. If so, then I don't think they
provide enough power in themselves. We've got a frequent requirement for
the style to change dynamically based on user actions within the
document. Often the cleanest way to store the user responses is by
manipulating attributes within the document itself, then firing style
rules that are affected by those attributes. This provides the
equivalent (in this instance) of global memory variables while
sidestepping the side effect issue. I'd hate to lose it.

Tony Stewart
RivCom
"Publishing Structured Information"
www.rivcom.com

		-----Original Message-----
		From:	Jani Jaakkola [mailto:jjaakkol@xxxxxxxxxxxxxx]
		Sent:	Wednesday, March 04, 1998 1:06 PM
		To:	xsl-list@xxxxxxxxxxxxxxxx
		Subject:	Re: Style vs. Transformation



		On Wed, 4 Mar 1998, Jacques Deseyne wrote:

		> Paul Prescod wrote:

		> >The style language is
		> > [...] 
		> >demonstrably a *complete* transformation: any
transformation that 
		> >can be expressed in any other transformation language
can be 
		> >expressed in the style language. It is also a *good*
transformation language.
		> > [...]
		> 
		> Has this been demonstrated somewhere ?  I'd be
interested in any pointers.

		This just follows from the fact that DSSSL-style
language is
		Turing complete. Therefore any computing problem that
can be
		solved with a computer can also be solved with the style
language.
		Transformations are just one class of computing
problems.

		The question which remains is, which way of doing
transformations
		is more elegant or just simply better or easier: the
Jade way or the
		DSSSL-transformation language way?

		IMHO,  Jade proves that the style language with SGML
		flow objects can have enough power and expressivity so
that the
		DSSSL-transformation language isn't really needed. But
i'm sure
		that not everyone will share this opininion.

		> >But I see no reason to require XSL implementors to
implement independent
		> >transformation and style application steps.
		> 
		> Probably, an independent transformation step seems
overkill in a _Style_ 
		> language. But why couldn't you expect requirements for
modifying the document's
		> structure during processing ? Do you really believe
that the frequent transformation 
		> needs among SGML users (evolution of DTDs, authoring
vs. repository DTDs, ...)
		> will all of a sudden disappear because they're using a
fixed concrete syntax ?

		The need for transformation language won't go away for
sure.
		The point is, that the style language with SGML flow
objects could
		also be the answer to transformation problems.

		- Jani


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


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


Current Thread