[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Transformation Language (was Re: removing HTML flow
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|