Subject: RE: XML Transformation Language (was Re: removing HTML flow obje cts?) From: Rob McDougall <RMcDouga@xxxxxxxxxxx> Date: Tue, 26 May 1998 18:22:14 -0400 |
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 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. 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. 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. 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. Rob -----Original Message----- From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxx] Sent: Tuesday, May 26, 1998 5:23 PM To: xsl-list@xxxxxxxxxxxxxxxx Subject: RE: XML Transformation Language (was Re: removing HTML flow objects?) [Snip] How would you characterize (perhaps by example) such a "feature of a generic XML processor"? Need XML processors necessarily have common features? Wouldn't different XML processor vendors wish to compete with product differentiation of features? ........ 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: XSL formatting model, Richard Lander | Thread | Re: XML Transformation Language (wa, Paul Prescod |
XSL formatting model, Lee Fife | Date | Re: XSL formatting model, Paul Prescod |
Month |