LISTSERV mailing list manager LISTSERV 16.0

Help for XML-L Archives


XML-L Archives

XML-L Archives


XML-L@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

XML-L Home

XML-L Home

XML-L  July 2000

XML-L July 2000

Subject:

Re: Servlets VS XSL?

From:

Kirstan Vandersluis <[log in to unmask]>

Reply-To:

General discussion of Extensible Markup Language <[log in to unmask]>

Date:

Wed, 26 Jul 2000 21:50:16 -0600

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (177 lines)

Ron,

At the risk of shamelessly plugging our company, I'd like to point out that
X-Aware's recently announced products DO provide a generalized method for
both Database-to-XML and XML-to-Database processing.  In general, we follow
a template strategy as you describe below.

One of the key features that enables XML-to-Database mapping and processing
is our nested component technology.  In a nutshell, each XML element is
assigned to a component for processing.  The component stores what it needs,
then passes the remainder to other components.  This happens recursively
until all data in the XML is stored in the appropriate place.

We provide a graphical environment to do the component assignments and
detailed field mappings, and a server component for the deployment.  We are
currently Windows platform-based, but our Java version is in the works.

A down-loadable version is available at www.XAware.com.  For a detailed
example of XML-to-Database mapping and processing, see
http://www.xaware.com/XML2Database/Overview.htm.

-Kirstan

---------------------------------------------------------
Mr. Kirstan Vandersluis
XAware.com (www.XAware.com)
E-mail: [log in to unmask]
Phone/Pager: (719) 930-6024


----- Original Message -----
From: "Ronald Bourret" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, July 21, 2000 11:46 PM
Subject: Re: Servlets VS XSL?


Demetris Zeinalipour wrote:

>Could anyone name me some advantages of using XSL Transformations in
>Applications where the underlaying Data Store is a Relational Database?
>
>I am trying for a long time now to improve to myself that there must be
>some
>advantages of using XSL Transformations on the server site against
>rendering
>SQL Results through a servlet (or asp, or any other server site approach)
>while almost ALL big software vendors are promoting this approach (e.g
>Oracle Portal-To-Go + Oracle Application Server, Microsoft SQL Server 2000,
>...), but the XSL approach didn't convinced me yet .
>I believe that there is an extra overhead (in development time & system
>performance) of transforming SQL Results into XML documents and then render
>the results with a XSL engine, instead of just rendering the SQL Results
>into the appropriate markup (WML,HTML,..).

I think there are several reasons for this:

1) Time to market
2) Flexibility
3) Reuse of existing technologies

Writing a processor that can transform any given set of tables into any
given markup language is an extremely non-trivial task. Consider, for
example, the following tables:

Table A: Column1  Column2
         -------  -------
         A1       A2

Table B: Column1  Column2  Column3
         -------  -------  -------
         B1       B2       B3

Now consider trying to extract this data into the following XML document:

<MyXML>
   <foo bar="A1">
      <baz>B2</baz>
      <boz><buz biz="A2">B3</buz></boz>
   </foo>
   <fee>B1</fee>
</MyXML>

While you could easily write a dedicated processor to transfer data in this
specific case, writing a generic one would mean writing a processor that was
almost unbelievably configurable. How do you know when to get which row of
data? How do you know how to nest the data? And, more to the point, how does
the user explain to the processor where they want the data to be placed in
the final XML document?

One way to do this is to use a template -- the user provides an outline for
the XML document, a set of SQL queries, and states in the outline where the
results of the queries are to be placed. This provides almost infinite
flexibility and is easy to implement but has one major drawback -- it only
works in the database => XML direction.

(More specifically, I should state that all such implementations I have seen
can do this only in the database => XML direction. My original guess was
that the reverse direction was not possible in the general case, but I am
now not so sure. Anybody who can solve it would have a very nice product and
make a lot of money. Anybody who could show it to be impossible would save
the would-be milllionare quite a bit of time...)

The alternative is to use a predefined model for transferring the data from
the database to XML, then using XSLT to transform the resulting XML document
to whatever XML the user wanted. This solution is presumably as flexible as
the template case, but has a couple of advantages from the perspective of
implementation:

1) Since the transformations are done by XSLT, the database companies don't
need to design/implement that part of the software. Good flexibility, good
time to market, and reuse of existing technology.

2) Since the model chosen by most major database companies is the obvious
object model -- that is, the following XML

   <A>
      <A1>valueA1</A1>
      <A2>valueA2</A2>
      <B>
         <B1>valueB1</B1>
         <B2>valueB2</B2>
         <B3>valueB3</B3>
      </B>
   </A>

is viewed as two objects -- object A with three properties (A1, A2, and
pointer-to-B) and object B with three properties (B1, B2, B3) -- the
database companies can reuse their object-relational engines to transfer the
data between XML and the database. More good time to market and reuse of
existing technology.

Furthermore, the user does not have to learn a new mapping model or template
language -- they simply use XSLT, which was already wide-spread at the time
most of the database companies started offering their solutions.

Now the point still remains that transforming the data directly from the
database to the target language would be faster than first transferring it
to XML and then transforming it with XSLT. I would like to point out several
things here:

1) If the order of data in the XML document does not match the order in
which data is retrieved from the database -- it is easy to construct
examples of this -- direct streaming of the data from the database to XML is
not possible. That is, some or all of the data must be cached in memory
while the remaining data is retrieved.

2) If the transfer software caches the data as a DOM tree, it can pass this
directly to the XSLT software, so in a well-architected system, there is no
inefficiency in building a DOM tree twice -- once to create the XML and once
to do the XSL transform. In effect, this is pretty close to doing the
transformation directly from the database. (I'm not sure if existing
databases actually do this. If not, they should get a clue and gain some
speed.)

3) In many cases, no XSL transform is necessary. This is because many
applications that extract data from a database as XML are data-oriented
applications using XML as a data transport. Previous to XML, they were
probably extracting data and constructing objects. For such applications,
data extracted according to the above object model does not need to be
transformed further -- it can be used by the applications as is.

(The only transforms needed by most such applications is the ability to
rename elements and attributes and to specify whether column data is placed
in an attribute or child element. Although this can easily be done as part
of the data transfer process, I'm not sure if all XML-enabled relational
databases offer these capabilities right now. Those that don't are requiring
an unnecessary transform.)

Well, I won't claim to have proven that the database => XML => XSLT approach
is necessarily faster than a dedicated transformation engine, but I hope
I've shown you the historical reasons it exists and why it is not an
unreasonable choice.

-- Ron Bourret
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2017
August 2016
June 2016
March 2016
January 2016
July 2014
April 2014
January 2014
July 2013
February 2013
September 2012
August 2012
October 2011
August 2011
June 2011
January 2011
November 2010
October 2010
July 2010
June 2010
March 2010
February 2010
January 2010
November 2009
September 2009
August 2009
July 2009
May 2009
March 2009
December 2008
October 2008
August 2008
May 2008
March 2008
February 2008
January 2008
December 2007
October 2007
August 2007
June 2007
March 2007
January 2007
December 2006
September 2006
July 2006
June 2006
April 2006
February 2006
January 2006
November 2005
September 2005
August 2005
July 2005
June 2005
May 2005
March 2005
January 2005
October 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
December 1997
November 1997
October 1997

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager