Subject: RE: XML Transformation Language (was Re: removing HTML flow obj ects?) From: Rob McDougall <RMcDouga@xxxxxxxxxxx> Date: Wed, 27 May 1998 10:13:55 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XML Transformation Language (wa, Paul Prescod | Thread | Fw: Signing of XSL scripts, Martin Bryan |
RE: XML Transformation Language (wa, Rob McDougall | Date | Re: XML Transformation Language (wa, Paul Prescod |
Month |