RE: XML Transformation Language (was Re: removing HTML flow objects?)

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxx>]

At 18:22 98/05/26 -0400, Rob McDougall wrote:
>Let's say I have a database product and I wish to import any XML
>document.  Now being considerate of my customer's needs, I want to
>leverage some industry standard if I can.  I notice that XSL allows
>someone to specify a series of patterns/rules to route the content into
>"flow objects".  This sounds like just the ticket.  I can define a few
>DB related "flow objects" e.g. table, row, column.  I would then ask the
>user to codify a set of rules using the XSL patterns to route their
>content into my flow objects.  Voila! I have an import mechanism, and my
>user has a transportable skill.  Everyone's happy.

I think you've just described "extensibility" as is implemented in DSSSL.

James' divined custom flow objects (semantics) related to emitting SGML
syntax so that a formatter designed to interpret the objects accordingly
would produce parsable data.

DSSSL's standardized extension mechanism allows authors to construct flow
object trees with custom flow objects.

Your experience with databases could lead you to meaningful semantics that
you would express as custom flow objects and their characteristics.

>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