[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

Subject: RE: XML Transformation Language (was Re: removing HTML flow obje cts?)
From: Rob McDougall <RMcDouga@xxxxxxxxxxx>
Date: Wed, 27 May 1998 09:42:44 -0400
python removing html
Paul,

I don't see how you can view applying styles to a document as a
transformation, but changing an (albeit structured) flat file into a
database is not.  I can't speak to the DSSSL flow objects, but the HTML
flow objects in the original XSL submission definitely DO overlap all
over the place (HTML tables have <TABLE><TD></TD></TABLE>, not to
mention everything occurs within a <BODY>).

I agree that every database will have XML import, but think for a moment
about what this entails.  Will the structure of the data being imported
*always* match the structure of the database?  Will it even *usually*
match the structure of the database?  If the two structures do not match
(which I believe will be the most common case), then how will the user
specify rules to transform the data's structure?  Sure they could code
up some Java, C++ or Python.  Couldn't you say the same thing for
transforming XML into HTML?  I think the principles are exactly the
same, merely the end result is different.

All applications that read "generic" XML will need the ability to
transform the structure of the incoming XML to match the structure they
need.  I think it would be highly advantageous if there was a standard
transformation language.

Rob

-----Original Message-----
From: Paul Prescod [mailto:papresco@xxxxxxxxxxxxxxxx]
Sent: Tuesday, May 26, 1998 6:58 PM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: XML Transformation Language (was Re: removing HTML flow
obje cts?)


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 agree that there should be a simple transformation language, but
database import is not transformation, in my opinion. Rows and columns
are
not a flow object. Flow objects do not overlap in the way that rows and
columns do. Within a couple of years, every database will have XML
import,
so XSL will not be very relevant. In the meantime, you can accomplish
the
same thing in a few lines of Java, C++ or Python code. I don't know why
you would want to use XSL in that situation.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time
http://www.geezjan.org/humor/computers/threes.html


 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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.