Fw: [Fwd: Improving Learnability of XSLT]

Cleaning out my inbox. This was sent to me and should be
part of the record to xsl-editors.
_____________________________________________________________________
Steve Muench - Developer, Product Manager, XML Evangelist, Author
"Building Oracle XML Applications" - www.oreilly.com/catalog/orxmlapp
  
----- Original Message ----- 
From: "Kimbro Staken" <kstaken@dbxmlgroup.com>
To: <Steve.Muench@oracle.com>
Sent: Tuesday, January 09, 2001 10:40 PM
Subject: Re: [Fwd: Improving Learnability of XSLT]


| Hi Steve,
| 
| I was forwarded this message by Tom Bradford as Tom felt I might be
| better able to provide useful feedback. First I need to say it is
| somewhat difficult for me to criticize XSL-T because I like it quite a
| bit. However, I also have experience in implementing it in a couple
| production applications and know that it has significant issues. I
| started working with the spec very early and built what had to be one of
| the first production applications around the technology in early 1999.
| Clearly the spec was still very immature and changing rapidly but even
| then I saw the value and potential that would come from utilizing what
| it provided and decided the benefit exceeded the risk. The application
| that was built works very well and even though it has never been updated
| to the final recommendation I can't imagine how we could have built it
| any other way. One other point is that most of my experience is in using
| XSL-T to transform XML to HTML.
| 
| The first significant problem with XSL-T is that it is very difficult to
| learn for all sets of users. More specifically the problem may be that
| for most programmers it is not intuitive at all as they are not used to
| declarative styles of programming. When you have programmers writing
| XSL-T code they tend to write code that is very procedural in nature and
| doesn't really leverage the power of the technology. So far it has also
| been my experience that Web developers don't get XSL-T at all, a
| stylesheet to them is CSS and they use a tool to create that. So far I
| haven't seen any decent tools for building XSL-T stylesheets. I guess
| tools will come but even more then with HTML I have the feeling they
| will be of questionable value. I almost see XSL-T development being a
| specialization in itself and that may be ok once its acceptance is large
| enough but right now it is a problem for companies that do not have the
| luxury of specialization. I see XSL-T falling into a kind of no mans
| land where web developers who are using Cold Fusion/ASP/PHP type
| languages find it too difficult and obscure and low level developers who
| are using C++/Java don't get it because it isn't object oriented enough
| or simply too "weird" (Basically translated as they don't understand it
| after 5 minutes so it must be bad). Of course most of these developers
| don't use XML either so maybe my point is moot. I guess we'll have to
| wait until XML developer becomes a more common area of specialization.
| 
| Overall though the single biggest problem with XSL-T and really XML in
| general is quite simply namespaces. This is such a big problem because
| namespaces are so important and definitely necessary but it is very hard
| for people to grasp the fact that the namespace prefix isn't what is
| important. Why this is so hard I don't know but I'm seeing it over and
| over and it constantly causes problems when writing XSL-T stylesheets.
| Things are made worse because the DOM doesn't properly handle that
| seperation and DTDs and namespaces simply do not get along. For instance
| everyone I know who has looked at XSL-T including all documentation that
| I've seen defines the tags as being <xsl:template match="..."> and I
| don't know anyone who will recognize <sns:template match="..."
| xmlns:sns="http://www.w3.org/1999/XSL/Transform"> as a valid XSL
| template. To everyone I've encountered the name of that tag is
| xsl:template not template with an associated namespace prefix. This
| becomes a very serious problem when you're trying to build an
| application against XML where the namspace URI isn't always the same. It
| is becoming common for the namespace URI to show the version of the
| namespace and to change as new revisions of a document type are
| released. The problem with this is that when it happens all your XSL-T
| stylesheets stop working unless you update the namespace URI and then
| any old documents that you encounter no longer work. A prime example of
| this is RSS, there are several different Dublin Core and RDF namespace
| URIs around and to build an application that works with all of them must
| have template rules for every case even when the tags are predominantly
| the same and the old stylesheet would still work perfectly with the new
| documents. Seems namespaces should have really included some way of
| setting a version other then through the URI. 
| 
| It would also be nice to allow dynamically changing what stylesheet is
| brought in by xsl:include and xsl:import. I think this is probably more
| of a problem for applications where a per user customized HTML page is
| the final target. I can think of several reasons why this may not have
| been included but it is quite limiting to not be able to do that and
| makes building customizable applications more complicated then really
| necessary. Overall this is a minor point as it can be worked around but
| it is annoying just the same.
| 
| A more serious problem is the lack of ability to dynamically change the
| mode attribute on xsl:apply-templates. This makes modes significantly
| less valuable and I'm not sure why this isn't allowed. I want to just be
| able to provide the mode to use as a parameter to the stylesheet without
| having to write a big xsl:choose to determine how things should be
| applied.
| 
| I'm sure this isn't anything you haven't already heard before but like I
| said I like XSL-T. To someone like Tom Bradford though, XSL-T is very
| foreign and his criticism derives from the fact that he doesn't
| understand it at any level of depth. He definitely falls into the
| catagory of "I don't understand it after 5 minutes so it must be bad".
| However, given that Tom Bradford is the best Java developer and
| architect I've ever known that does reflect poorly on XSL-T's
| accessibility. Unfortunately I don't know what could be done to solve
| that problem as the power of XSL-T derives from a model that is
| inherently foreign to both procedural and OO developers. It is good that
| XSL-T supports both push and pull models but maybe that also makes it
| too complex and kind of "perlish" meaning "there is always more then one
| way to do it". To developers like Tom being perl like is not a good
| thing.
| 
| Hopefully this is helpful.
| 
| Thanks
| 
| -- 
| Kimbro Staken
| Chief Technology Officer
| dbXML Group L.L.C
| http://www.dbxmlgroup.com

Received on Friday, 28 September 2001 04:37:23 UTC