RE: XML Transformation Language (was Re: removing HTML flow

Paul,

You seem to have changed your mind since last March.  In a message dated
Tue 3/3/98 7:55 PM you stated (and I quote):
"The style language is demonstrably a transformation. It takes input and
transforms it into output. It is also demonstrably a *complete*
transformation: any transformation that can be expressed in any other
transformation language can be expressed in the style language. It is
also a *good* transformation language."

It was *you* that convinced me that styling *was* a transformation!

I'm afraid I also disagree with you WRT one dimensional vs. two
dimensional objects.  Any two dimensional object can be represented as a
one dimensional object, just as a two dimensional array in C can be
accessed as V[2][2] or V[2*2] .  Another example is a two dimensional
image can be stored as a stream of bytes.  XML can be used to represent
2 dimensional objects such as a relational database.  Anyway, this is
off-topic.  The intent of my example was to show why one might wish to
use a transformation syntax in an non-styling application that accepts
generic XML.

> 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?
I never said I wanted to distribute the mapping over the web.  I never
said anything about the web.  I just want to re-use my XML document in a
variety of contexts without having to learn a new syntax every time I
try and bring it into one of those new contexts.  Is that too much to
ask?

Rob

-----Original Message-----
From: Paul Prescod [mailto:papresco@xxxxxxxxxxxxxxxx]
Sent: Wednesday, May 27, 1998 11:01 AM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: XML Transformation Language (was Re: removing HTML flow
obje cts?)


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


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
<- Previous	Index	Next ->
Re: XML Transformation Language (wa, Paul Prescod	Thread	Re: XML Transformation Language (wa, Paul Prescod
Re: XSL formatting model, Chris Lilley	Date	Re: XSL formatting model, Sean Russell
	Month
<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home
RE: XML Transformation Language (was Re: removing HTML flow obje cts?)
