Re: Leventhal's challenge misses the point

[stinney@xxxxxxxxxxxxx (Steve Tinney)]

I second JamesT's point, having just been through a trajectory of 
discovery over the last week or two in which I came to the same 
conclusion.  I am building composite documents of various kinds from 
datesets and text, and started off using XQL to select records, then soon 
discovered that I needed just a little more (don't just select, but also 
add a bit here, take away a bit there) and that using XSL was inevitable.

I am still learning about all these tools, but there is a lot of terrific 
work being done out there.  As far as I can tell, there is still not 
(quite) a full XSL implementation which can be fed DOM nodes from 
arbitrary places in a document and return the results; SAXON is close, 
and I guess will be the first to do this (correct me if I'm wrong).  XT 
is embeddable, but I haven't looked hard enough at the source to 
determine if it could easily work with DOM.  With that, and the 
persistent DOM from GMD, dynamic document creation with low server 
overhead will be relatively straightforward, and without the additional 
layer of an SQL server.

 Steve

James Tauber wrote:
> 
> > DOM with query language support will look a little less busy:
> >
> > var result = xmlDoc.getElementsByQuery("//section/title");
> > for (var i = 0; i < result.length; i++)
> >   document.write("<h1>" + result[i].nodeValue + "</h1>");
> 
> Yes, but this only serves to highlight my original argument on XML.COM. As
> you attempt to build a common library to make transformation easier with the
> DOM, you end up with something more and more like XSLT anyway.
> 
> JamesT
> 
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


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