Ken,

I don't think you've quite got my point (but you're close :) ).  While I
applaud the extensibility of DSSSL and (hopefully) XSL, that mechanism
is designed to be used in addition to, but not as a replacement of, the
core flow objects.  I see it more as a "I've got an XSL processor, now I
want to do something style-related that the originators didn't foresee".
Using it to do a database import within an existing style processor
qualifies as something that "the originators didn't foresee", but seems
a little too extreme (although technically possible, I suppose).

Just as ECMAScript is a standardised scripting language that can be
embedded in a wide variety of applications, I see the XSL transformation
"language" as a standardised XML transformation language that could be
embedded in a wide variety of XML applications.  I think web designer's
lives would have been much easier if ECMAScript had been standardised
*before* IE and Netscape embedded it in their browsers.  Likewise, I
think XML programmer's lives will be simplified if W3C standardises the
transformation syntax *before* a plethora of XML tools are implemented.

I find your last statement very encouraging.

Cheers,

Rob

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxx]
Sent: Tuesday, May 26, 1998 8:17 PM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: RE: XML Transformation Language (was Re: removing HTML flow
objects?)

[Snip]

>I see the patterns/rules structure of XSL/DSSSL as being fundamental to
>any application that intends to receive generic XML.  Sure they can
>re-invent the wheel if they want, but I wouldn't recommend it.  Of
>course, they might _have to_ if the XSL pattern/rule capabilities are
>inadequate.  IMHO, this would be the worst of all possible cases.  If
>XSL's transformation capabilities aren't robust, then we could get a
>thousand different (incompatible) variations on the XSL syntax.  

Here's where you've lost me.  Given the existing processing model of
building an _arbitrary_ flow object tree (without restriction) of both
standardized and (hopefully) customized flow objects (and their
characteristics), I don't see what is missing.

>I'd
>like to see vendors differentiate their products by offering more "flow
>objects" with more characteristics, rather that re-inventing another
>patterns/rules syntax.

But I think that is precisely what we'll have if the WG implements
extensibility.

>I'd like to see W3C step in and separate the transformation syntax
>effort from the XSL flow object effort so that the transformation
syntax
>is built from the ground up to be a general facility.  

As I think it currently is a general facility in the original draft
(except
it isn't clear how (if?) extensibility is addressed).

>Without having
>examined the current XSL WG draft that is due out in July, I worry that
>style specifics may creep in to the transformation facility, or that
>they may miss some important generic feature because of the focus on
>style.

If the WG follow the DSSSL processing model, all such "style specifics"
will be captured entirely in the flow objects and their characteristics,
and nowhere in the specification syntax.

........... Ken

--
G. Ken Holman            mailto:gkholman@xxxxxxxxxxxxxx
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com
Box 266,                             V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0         F: +1(613)489-0995
PGP Privacy: http://www.cyberus.ca/~holman/gkholman.pgp
Training:  http://www.CraneSoftwrights.com/schedule.htm
Shareware:   http://www.CraneSoftwrights.com/shareware/


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


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