Re: Re: [xsl] Java Transformation

Subject: Re: Re: [xsl] Java Transformation
From: Ramkumar Menon <ramkumar.menon@xxxxxxxxx>
Date: Fri, 22 Apr 2005 00:36:21 +0530
Hi Charles,

Good observations.
A couple of points here.

>> It is easier to use a tool you know than to use a tool you don't
know, even if the tool you know isn't "the best tool".

I agree with you. I do not have any reservations against the usage of
XSLT for transformations. But I was referring to the "reason" for the
choice of XSLT [an XML structured Document] in first place.

>>Ask yourself if it is easier to get data from an ANSI SQL database
by using a SQL SELECT statement or by opening each table and writing
nested for-each loops to find the related data in several tables.

I agree with you on this one too. I was not specifically referring to
Java, but a higher level language that can inherently supports
transformation constructs, but is still programmatic.
For instance, imagine having to write an XML structured Query to
access your database table. [a database table can also be compared to
a structured document]
SQL is a simple programmatic language that you can use to extract data
from your DB. I was thinking of something on similar lines for XML
Transformations.

ciao,
Menon.

On 4/22/05, cknell@xxxxxxxxxx <cknell@xxxxxxxxxx> wrote:
> It is easier to use a tool you know than to use a tool you don't know, even
if the tool you know isn't "the best tool". As a person familiar with both
declarative and procedural programming tools it is my view that the easier way
to process XML is with XSL rather than a procedural programming language like
C or Java.
>
> Ask yourself if it is easier to get data from an ANSI SQL database by using
a SQL SELECT statement or by opening each table and writing nested for-each
loops to find the related data in several tables. The answer is obvious to me
and the parallel between XSLT and SQL is very direct.
> --
> Charles Knell
> cknell@xxxxxxxxxx - email
>
>
> -----Original Message-----
> From:     Ramkumar Menon <ramkumar.menon@xxxxxxxxx>
> Sent:     Fri, 22 Apr 2005 00:08:08 +0530
> To:       xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  Re: [xsl] Java Transformation
>
> oops!!! I think I wasn't clear with my question at all ... Sorry.
> Yeah, I definitely agree that there are a huge number of smart XSLT
> Mapper Tools in the market today....
> My question was on the fundamental notion of usage of an "XML based
> structure" like XSLT to represent processing/transforming "logic". I
> was wondering if logic could be easier written/expressed if a Non-XML
> programming language, rather than within XMLish documents.  I
> definitely see your point about today's User affording to stay
> agnostic of the details of the mapping for most common business use
> -cases. But yeah, my question stays.
>
> -Ciao,
> Menon.
>
> On 4/21/05, Aron Bock <aronbock@xxxxxxxxxxx> wrote:
> > Recently somebody's bee doing announcements here about "Tiger XSLT".
> > Haven't tried it, though.
> >
> > Regards,
> >
> > --A
> >
> > >From: Ramkumar Menon <ramkumar.menon@xxxxxxxxx>
> > >Reply-To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > >To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > >Subject: [xsl] Java Transformation
> > >Date: Thu, 21 Apr 2005 22:46:51 +0530
> > >
> > >Hi All,
> > >
> > >Whenever I open up an editor and view a complex XSLT, I feel that the
> > >mapping logic is easier to be written and interpreted, if written in a
> > >simple but powerful programming language [a high level language that
> > >can be generated using javacc or something] - with an import/export
> > >facility to XSLT.
> > >Is there any existing infrastructure in place to achieve this?
> > >Surely, I speak from the developer's perspective. With simple mapping
> > >tools available in the market now which can generate you mappings, you
> > >really need not know all the nitty gritties of XSLT at all for most
> > >common business use cases.
> >
> > _________________________________________________________________
> > Don't just search. Find. Check out the new MSN Search!
> > http://search.msn.click-url.com/go/onm00200636ave/direct/01/
> >
> >
>
> --
> Shift to the left, shift to the right!
> Pop up, push down, byte, byte, byte!
>
> -Ramkumar Menon
>  A typical Macroprocessor
>
>



--
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
 A typical Macroprocessor

Current Thread