OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: transformations

[ Lists Home | Date Index | Thread Index ]
  • From: Didier PH Martin <martind@netfolder.com>
  • To: Wayne Steele <xmlmaster@hotmail.com>, paul@qub.com, xml-dev@xml.org
  • Date: Mon, 20 Nov 2000 14:51:16 -0500

Hi Wayne,

Wayne said:
   A. Slow processing time
      I have seen several implementations (MS, and I think Sun) of
'compiled' stylesheets. This should be a big performance improvement, and
should keep improving.

Didier replies:
Have you tried both Microsoft MSXML (with pre-compiled stylesheet) and Sun
XSLT to servlet compiler? I experimented with both and wasn't deceived by
the processing speed. However, this was the case with several Java XSLT
engine. To be precise, what are the XSLT engines you found too slow.


Wayne said:
   B. No Decent Error processing.
      I remember c used to have the same problem. This is just a sign of the
immaturity of the language. You've got XSLT processors, right? Now you want
XSLT-Lint?

Didier replies:
When using MSXML (latest version) integrated with the browser I am able to
get the faulty line and error position. The error message is maybe not the
best in the world but I should say that I never got development environment
giving me good error report anyway. Just remember some Java or C++ error
reports. This is natural, parsing and compiling techniques have some
limitations. It seems that several engines are not better or worse than the
current state of the arts. Have you tried the new XSLT IDEs?

Wayne said:
   C. Microsoft's Non-Standard Implementation
      MSXML 3.0 looks to have pretty complete XSLT and XPath
implementations. Non-Standard extensions have been pushed into the ghettos
specified in the XSLT Rec. While this has been (and still is) a headache, I
think they're to be commended for a smooth migration to the standard,
following through on the promises they made from the get-go
(Disclaimer: I used to work with this team at Microsoft).

Didier replies:
It seems that the latest implementation is pretty much conformant when you
run the OASIS tests on it. So...

Wayne said:
People who push XSLT to the limits I think know they're "using a wrench to
pound a nail". But it does get the nail in, right? Who wants to learn (or
invent, in this case) a whole new tool, when they can make the one they have
work? Consider it a form of 'code-reuse'.

Didier replies:
Up to now we precisely didn't saw a lot of XSLT pushed to the limits and - I
think - this is precisely the problem. We do not know well what are these
limits. Recently, we made an application using W3 technologies and used XML
to encode protocols (SyncML), data model (semantic links) and rendering
languages (WML, VXML, XHTML). We discovered that indeed XSLT put the
developer in a new seat: the seat of a meta programmer. Why? because, if you
use - for instance - XSLT to transform a data model into a rendering format,
you may use XSLT as a "just in time" program creation tool. The end program,
let's say a DHTML apps running in a browser can have its code created on the
basis of a particular device profile and a particular user profile. The
produced code is not the same for two different users. We where totally
surprised to discover that XSLT is a tool that can be  used to create
programs and thus, XSLT can be a "meta programming" tool. The developer no
longer creates the apps' code but the XSLT transformation sheet is used to
create it by incorporating rules dependent on the user and device profile
(just to name a few inputs for the "just in time" program creation). We just
scratched the surface and still explore what we just discovered. So it
seemed to me that these limits are still fuzzy and needs to be explored.

It seems that the real problem with XSLT is:
a) mediocre implementations (compliant but not optimized for speed). Off
course, this is natural, XSLT is still young and the first wave was a wave
of prototypes. The next wave should be better if optimization techniques are
included and better memory management is incorporated.
b) The developers still do not fully understand this new tool and how to use
it. This is understandable, the language is quite new and few sophisticated
applications are out there to show the way. A lot of buzz, a lot of
discussions, few real life examples to learn from or build on.

Sorry, I tend to see the glass half full instead of half empty and see the
world as a big playground to be explored even after 22 years working in this
field (Does this means I am an adult now? :-)

cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: xml devcon 2000 (http://www.xmldevcon2000.com)
		 Wireless Summit NY (http:www.pulver.com)
	       xml devcon 2001 London (http://www.xmldevcon2000.com)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS