Subject: Re: XML Transformation Language (was Re: removing HTML flow obje cts?) From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx> Date: Wed, 27 May 1998 11:01:25 -0400 |
Rob McDougall wrote: > > 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 usually reserve the word "transformation" for conversion between likes. E.g. text string to text string is transformation. XML document to XML document is a transformation. Tree to tree is a transformation. Converting a flat file into a tree (i.e. "parsing") is not usually considered transformation. Nor is converting a tree into a rendition (i.e. "styling"). Hence, I don't feel that converting a tree into a database would be considered transformatoin. > 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>). TDs within TABLEs do not overlap, but rather one is contained within the other. You may think of a table as this: <TABLE> <TR><TD><TD><TD><TD></TR> <TR><TD><TD><TD><TD></TR> <TR><TD><TD><TD><TD></TR> <TR><TD><TD><TD><TD></TR> </TABLE> but to the parser, it is identical to this: <TABLE><TR><TD><TD><TD><TD></TR><TR><TD><TD><TD><TD></TR><TR><TD><TD><TD><TD></TR><TR><TD><TD><TD><TD></TR></TABLE> It is one long string. But the tables, columsn and rows that a database manipulates are not strings, but are really two-dimensional objects (conceptually). Perhaps "overlap" is the wrong word to describe the relationship between rows and columns in a two dimensional object, but I think that you will understand why it is a very different situation. You are talking about conversion from one data model to another. > 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? I can think of a few ways. #1. You can do a transformation from one textual format ("ordinary XML") to another textual format ("XML that fits our database schema") This looks like XML->tree->tree->XML->database or XML->events->XML->database . An XSL-like XML transformation language could do this. #2. You can do a transformation from one XML tree structure ("the output of the parser") to another XML tree structure ("a tree that fits our database schema") This looks like XML->tree->tree->database . An XSL-like XML transformation language could do this. #3. You can do a *conversion* from the XML tree structure to a two-dimensional table/column model. XSL is *not* appropriate for this, because XSL is designed for tree->tree conversions. You could invent a language for doing this, and hopefully this language will be embedded in major database systems. If it is powerful enough, then you will not need to use it in tandem with one of the other systems. If it is not, then you will have to do a tree->tree transform first. > Sure they could code > up some Java, C++ or Python. Couldn't you say the same thing for > transforming XML into HTML? Yes, but the difference is that your database schema is inherently non-portable. We need XSL so that we can ship random XML documents to random people. But why would you want to distribute your XML->database mapping over the web? > 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. XSL does only tree->tree. So it can map into tables, rows and cells (easily), but will probably not be efficient for real 2D database tables. To handle real 2D tables elegantly, you would want named rows and cells, and the ability to peg content directly to rows and cells. You would also want to be able to verify constraints on cells before inserting them into the database. You want to check that every row has the data that it is expecting. I'm sure there are other things specific to the tree->database problem that I haven't thought of yet as well. 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XML Transformation Language (wa, Rob McDougall | Thread | RE: XML Transformation Language (wa, Rob McDougall |
RE: XML Transformation Language (wa, Rob McDougall | Date | RE: XSL formatting model, Richard Lander |
Month |