I'm prototyping an app that uses XML config files. This morning I knew just enough XML to ask stupid questions, and even less about XSL. But with a little help from O'Reilly's "XML Hacks" (the Socket Wrench book) and w3.org I learned quite a bit.
My goal was to convert an XML file defining a series of nodes, each with six attributes, into a list of lists, with the attributes in the inner lists in a standard order regardless of their order in the XML. (I was surprised how many quick & dirty solutions just copy things in document order, which seems like asking for trouble!) I created an .xsl file that performed the transform, which I tested by opening the .xml file in a browser. Woo hoo, the transform works!
Then I used tclXSLT to do it in Tcl thusly (where $xml and $xsl are the contents of the respective files):
package require dom package require xslt set xmldoc [::dom::libxml2::parse $xml] set xsldoc [::dom::libxml2::parse $xsl] set listify [::xslt::compile $xsldoc] set txtdoc [$listify transform $xmldoc] set bands [::dom::libxml2::serialize $txtdoc -method text]
That works, so obviously I've found *a* way, but when venturing into unknown territory I like to keep to the *right* way as much as possible.
One question that arose immediately was why do I have to say "-method text" when the XSL already specifies <xsl:output method="text" />? I guess for no other reason than that the man page says I have to, huh?
The other question is one of the whole approach. Having a separate .xsl file makes it easy to view the XML files in a browser, which is potentially useful. But I could have just walked the XML doc tree in Tcl, pulling out attributes and stuffing them in a list. In fact, the code to do this would look a lot like the templates in the .xsl file.
Having just celebrated my birthday (29... again!), I'm am feeling a bit more gray. To answer the obvious question: How old am I? I'm old enough to know better, but young enough not to care!
Your approach looks fine to me. The idea of transforming XML into a Tcl script using XSLT and then eval'ing it is something I've been doing quite alot lately. I've also done a system on Windows using DOS batch scripting in the same fashion (but relatively clunky compared to the use of Tcl).
As far as the -method option is concerned, you must specify it to the dom::serialize command because the dom package is separate to the xslt package. At that point in the document's lifecycle it simply does not know that its intended serialisation is as text rather than as XML. In fact, there's nothing to stop you from producing an XML result document and then serialising it as text, or vice versa. The stylesheet provides an option for retrieving the serialisation method, so you can do this:
sorry... no beard (just a little bit older than 29...)
I am developing a project with tcl on XML, but I was forced to use java saxon XSLT procesor in order to get 2.0 features.
I understood that xslt package for TCL (bound to the underlying GNOME libraries) is still supporting 1.0. Anyone knows about plans for 2.0 implementation?
Massimo wrote: > I am developing a project with tcl on XML, but I was forced to use java > saxon XSLT procesor in order to get 2.0 features.
> I understood that xslt package for TCL (bound to the underlying GNOME > libraries) is still supporting 1.0. Anyone knows about plans for 2.0 > implementation?
TclXSLT is absolutely dependent on the underlying library, libxslt, for 2.0 support. I haven't seen any activity on developing 2.0 support (though there is an effort to support XSD that may help to support XSLT 2.0).
Support for XSLT 2.0 will not be a trivial undertaking. libxslt already includes certain features that are in 2.0 (xsl:document, exslt:node-set), but the changes to XPath (sequences, additional functions) will require a large amount of engineering. The libxslt mailing list is the best place to ask about this.
I'd love to see support for 2.0 in TclXSLT/libxslt! Alas, I don't currently have the resources (== time) to put into making it happen.
John Seal wrote: > I was > surprised how many quick & dirty solutions just copy things in document > order, which seems like asking for trouble!
I should point out that some of the solutions I dabbled with were regexp solutions. I came up with a surprisingly simple expression that sucked out all the data, but in document order, and it would do horrible things if ever an attribute were missing. I seem to recall seeing a thread about the dangers of trying to parse XML via regexp, and decided that it was madness to continue down that road.
|
