This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Debug Support in XSL


Those who want to build user-friendly XML
transformation tools should look at the more
conventional database-oriented products such as:

Sagent (also sold as Oracle Data Mart Suite)
Metaphor (bought by IBM (?) some time ago)
Informatica
Microsoft DTS

In my opinion Sagent has the best implementation.  These
tools are of course proprietary and aren't based on standards
except (maybe) SQL.  The transformations rely on
reusable "capsules" of code.  The capsules can be
strung together graphically.  While the overall
structure of a transformation job is somewhat declarative,
the code capsules are not.  In contrast,
unless you resort to scripting, XSLT is
fully declarative.

The products I listed are designed to
work with very large relational data sets.
They are just starting to
incorporate XML, some more so than others.

The schema for relational data is pretty much
fixed.  XSLT can transform data that conforms to virtually any schema,
as long as it's XML.  XSLT's job is  therefore significantly more difficult.

I believe that ..

1. XSLT is too complicated for average developers.
2. A decent GUI XSLT tool, per se, will never exist.
   A usable tool, however, might generate XSLT.
3. Reusable capsules are very powerful.  If you
   can't leverage the work of other developers, say, on
   the Internet, then you have to constantly start from
   scratch.  I don't know how many times I've read
   about the Muenchian Method only to be completely
   baffled by it.  Tasks that are conceptually easy
   to understand should be easy to do.
4. Loading entire documents into
   memory is unrealistic.  A streaming or hybrid
   paradigm is required for large data sets.
5. Most data today exists in relational databases.
   Extraction and transformation tools need
   to be able to incorporate relational data easily, with
   **no coding**.  The database vendors will never support
   XML in exactly the same way, so some sort of tool
   will have to bridge the gap.

Given that Informatica and Sagent are publicly traded
companies, we're bound to see a company emerge that
transforms XML and relational data in an easy-to-use
and high-performance fashion.  I doubt their
technology will be fully based on XSLT.

XSLT serves a critical purpose today and will
continue to do so for many years to come.  But XSLT
is a tool for highly skilled programmers whereas
"the rest of us" need an integrated solution.

http://xmleverywhere.com

--- In xml-dev@egroups.com, "G. Ken Holman" <gkholman@C...> wrote:
> At 00/08/25 09:41 -0500, Bullard, Claude L (Len) wrote:
> >Do you or anyone else know if these WYSIWYG XSL
> >editors will be handling the complexities of
> >authoring and debugging the XSL transforms?
>
> Personally, I don't, which is why I'm anxious to see what Whitehill offers
> to see the way they support their claims.  It is exciting to think these
> tools are on their way.
>
> I have seen "editing assistants" which walk you through the authoring
> process giving you a montage of what you're working with, what you've done
> in your stylesheet, and the results therefrom ... but I don't use them
> myself and I wouldn't necessarily call them WYSIWYG editors from my
> personal sense of what is needed


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]