Ken,
Thanks for bringing this up ... I agree unequivocably with you on all
points, and would like to add a few of my own.
1) The statement XSLT is not useful for translation from other formats is
not completely true either. It is not as easy to translate from other
formats (especially binary ones), but you have in place many if not most of
the pieces necessary to write a basic parser for a number of text-based
formats. Moreover, with language extensions (which are contained in most, if
not all, XSLT parsers) you can actually farm out some of the work for even
binary formats to components while still maintaining the XSLT environment.
Similarly, while not perfect for this work, you can use XSLT to generate a
surprisingly wide number of output formats. Consider that most programming
parsers act as mechanisms to convert token sequences into what are
essentially directed graphs. Once tokenized, the parsing back into a binary
representation is typically just a matter of rewalking that graph structure
with templated mechanisms ... which sounds remarkably similar to what goes
on in XSLT. Thus an XSLT conversion from XHTML to RTF is quite doable,
while one from RTF to XHTML using XSLT is at least conceivable, if not
necessarily the best tool to do the job.
2) XSLT and XSL-FO are two very different things, and it is necessary to
differentiate between them when discussing XSL. XSLT is actually quite
useful for working with enterprise data in a number of contexts -- anything
from creating business rules to piping in additional streams to converting
between differing standards. That some of these require a modicum of XSLT
acumen (at the moment) shouldn't be seen as a negative -- it's much easier
to build modular components out of XSLT that can be used for any number of
alternative actions than it is to do the same thing in ASP/JSP. The amount
of infrastructure code drops, the ability to separate presentation and code
logic increases, and the degree to which such structures can be automated
rises as well.
XSL-FO, on the other hand, is a mess -- complex, unwieldy, poorly supported,
and serving a very limited need (essentially sending out information to a
text domain). It converts the relatively clean syntax of CSS into a much
more complicated attribute assignment structure (and for those that argue
that this is to make it easier for working with consider that you can
convert CSS styles into attributes dynamically using string-before() and
string-after()).
3) I think there is an active campaign on the part of the EDI promoters to
spread as much doubt and disinformation about XSLT as possible (I'm not
saying it is a conspiracy, but I have noticed the trend), because it is
ultimately XSLT that effectively provides the one major difference between
EDI and XML. The EDI approach works on the principle that the data
structures come from a common pool but that there are many variations on
this pool that can only be handled by the interventions of VANs. XSLT, on
the other hand, provides at least a first level mechanism to eliminate this
bottleneck by saying that if two companies do not have common standards,
they CAN create a mechanism using an open, non-proprietary format that can
be crafted without specialized tools for the explicit purpose of mapping
between the two formats themselves. Will some companies outsource this? Of
course. Will some companies let another company mediate the transactions? Of
course. Will all companies do this? No, of course not. If you're a small
vendor who can suddenly exchange financial information with much larger
customers, you're going to look for the most cost effective technique you
can, and the easiest way to do that is to either standardize on existing
formats or build your own conversions.
4) XSLT can be improved -- I don't think anyone can argue that. However, you
can do a surprisingly large amount of things with XSLT that would fall into
purview of "traditional" programming, and more, because XSLT is largely a
pattern oriented language, you can apply the same stylesheet to a wide
number of possible variations of XML source. Moreover, XSLT can seem
confusing until you understand the paradigm, then its actually not much more
complex than any scripting language (indeed, as an exercise, string off all
of the "<" and ">" symbols and remove all namespaces prefixes from a
traditional XSLT file. What you have left is actually surprisingly legible,
and in many respects much easier than a traditional C++ language file would
be.
-- Kurt Cagle
-- Author, XML Developer's Handbook. Sybex
----- Original Message -----
From: "G. Ken Holman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 03, 2000 2:11 PM
Subject: Re: Are there really any benefits?.
> At 00/07/03 00:52 -0400, David RR Webber wrote:
> >Message text written by Richard Hayes
> > >
> >Modern computers systems need to parser information between ERP / CRM /
> >MRP II / etc and it is far easier using a common language XSL. What
> >will happen there will be a device probability software agent (bot) that
> >learns any data format and automatically translates it into a usable
> >formats.
> ><<<<<<<<<<<<
> >
> >Richard - there is only one major flaw in this concept!
> >
> >XSL is not the right tool!!
>
> Wait a minute here ... XSLT (XSL Transformations) is used for translation,
> XSL for style semantics. I'll assume Richard meant to reference XSLT and
> not XSL since I think he is talking about vocabulary transformation. I
> won't comment on the automation scenario he has described, I only want to
> comment on the use of XSLT: I don't see why XSLT is not (necessarily) the
> right tool to parse and translate XML derived from different systems.
>
> XSLT is not useful (and shouldn't be promoted as being so) for conversion
> from non-XML to XML (as would, say, Omnimark) ... but if Richard is
talking
> about translation between instances of XML vocabularies, then XSLT can be
> very useful.
>
> >XSL is a style language, it is being
> >pressed into service as a business information transformation
> >toolset. It is poorly suited for the role.
>
> I unreservedly disagree that XSLT is categorically inappropriate for XML
> instance vocabulary transformation ... it is very appropriate in many
areas
> and I anticipate its wide acceptance in EDI-related applications utilizing
XML.
>
> For example: an XSLT processor can even play a role as the front-end to an
> application adapting to XML inputs with far greater flexibility than using
> just an XML processor as a front-end.
>
> >Fortunately people (including the W3C!) are working on
> >successor and better equipped tools.
> >
> >Message: don't bet the farm on XSL, even for forms,( see xhtml, XForm
> >are showing better ways).
>
> Now are you talking XSL formatting or XSL transformation? Why are you
> bringing forms into this discussion? I thought Richard was talking about
> information transformation.
>
> >Your example above also pre-supposes that all XSL processors
> >give you consistent results. This is simply not the case, only
> >talked about right now.
>
> Again I disagree! Many processors available *today* are
> interchangable. Vendors are working towards compliance. I chair the
OASIS
> XSLT Conformance Technical Committee and there is demand in the industry
> for a conformance test suite from our efforts.
>
> >XSL is a complex tool, and from complexity
> >comes several side-effects that limit its usefulness.
>
> Complexity is in the eye of the beholder. Such a blanket statement is
> unfair and judgmental.
>
> >However, used sparingly, as it was designed to be, XSL can deliver
> >good results, albeit at a cost in programming time.
>
> XSLT's "transformation by example" paradigm does not require programming
> knowledge to be used successfully. It was designed to be usable by
> non-programmers.
>
> To learn more about XSL, XSLT and XPath, you can participate in:
>
> http://www.mulberrytech.com/xsl/xsl-list
>
> There is also an *excellent* FAQ at:
>
> http://www.dpawson.co.uk
>
> I find unqualified and unsubstantiated claims of inappropriateness are
> difficult to defend, so I hope the reader will make their own decision
> about how easy or difficult XSLT is to use. There are a number of free
> resources noted in the FAQ where one can learn more. I've released on our
> web site a free download excerpt (covering the context and introduction to
> XSLT) of my own book.
>
> I hope this helps.
>
> .................. Ken
>
> --
> G. Ken Holman mailto:[EMAIL PROTECTED]
> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/e/
> Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
> Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
> Book: Practical Transformation Using XSLT and XPath ISBN1-894049-04-7
> Next instructor-led training: 2000-09-19/20,2000-10-03,2000-10-04,
> - 2000-10-05,2000-11-13,2001-01-27
>
>
>
> ------ XML/edi Group Discussion List ------
> Homepage = http://www.XMLedi-Group.org
>
> Unsubscribe = send email to: [EMAIL PROTECTED]
> Leave the subject and body of the message blank
>
> Questions/requests: [EMAIL PROTECTED]
>
> To receive only one message per day (digest format)
> send the following message to [EMAIL PROTECTED],
> (leave the subject line blank)
>
> digest xmledi-group your-email-address
>
> To join the XML/edi Group complete the form located at:
> http://www.xmledi-group.org/xmledigroup/mail1.htm
>
>
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
