Curiouser and Curiouser!

Curiouser and Curiouser! on xslt http://matt.blogs.it/ RSS feed for topic xslt Copyright 2006 Matt Mower Squib/0.1 self@mattmower.com self@mattmower.com en-gb Transmorpher 1.0 announced Mon, 06 Jan 2003 16:44:50 +0000 <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> Transmorpher 1.0 Fluxmedia and INRIA are pleased to announce the availability of Transmorpher 1.0. Transmorpher is a software tool for defining and processing complex transformations of XML documents. It can accept external transformations (e.g., XSLT stylesheets) and provide a simple transformation language offering unit transformations (suppression, renaming, regular expression substitutions and query facilities). In addition to generating, transforming and serializing XML documents, it features constructors like merging, dispatching, querying, iterating, and composing transformations. These transformations can have several input and output streams. New implementation of these constructors can be plugged in Transmorpher. Transmorpher can be used as a compiler, an interpreter, a Ant task, a Servlet generator or embeded in another program. Transmorpher 1.0 is written in Java 1.3. It is the first full implementation of Transmorpher as presented in [1]. This version does not put emphasis on performances that we will consider in ulterior version but on functions. Transmorpher takes advantage of external resources (XML parsers, XSLT servers, Regular expression substituers and many other optionnal components). A graphic user interface, FlowComposer(<A href="http://www.fluxmedia.fr/flowcomposer/">http://www.fluxmedia.fr/flowcomposer/</A>), is under development at Fluxmedia. Transmorpher is available to everyone (sources included) from <A href="http://transmorpher.inrialpes.fr/">http://transmorpher.inrialpes.fr</A> under the GPL license (other licenses possible). Transmorpher is a joint development of the Exmo team(<A href="http://www.inrialpes.fr/exmo">http://www.inrialpes.fr/exmo</A>) of INRIA Rhône-Alpes and Fluxmedia. Its development is being supported by a ODL grant from INRIA. [1] Jérôme Euzenat, Laurent Tardif, XML transformation flow processing, Markup languages: theory and practice 3(3):, 2002 (a pre-version is available at <A href="http://transmorpher.inrialpes.fr/wpaper/">http://transmorpher.inrialpes.fr/wpaper/</A>) Contact: <A href="mailto:transmorpher-dev@inrialpes.fr">transmorpher-dev@inrialpes.fr</A> From <A href="mailto:xml-dev@lists.xml.org">xml-dev@lists.xml.org</A></BLOCKQUOTE> This looks like a very interesting piece of software for augmenting XML processing in cases where XSLT is required, but too complex or unable to perform certain operations.  Or for structured processing involving a number of operations in sequence.  I like the sound of the FlowComposer as well.   http://matt.blogs.it/entries/00001036.html XML database reporting tool Wed, 08 Jan 2003 11:28:52 +0000 <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> Just released: the 1.0 version of xReporter, open source, XML-based Apache Avalon/Cocoon-based database reporting framework, available from <A href="http://xreporter.cocoondev.org/">http://xreporter.cocoondev.org/</A> Most compelling features: <UL> <LI>multiple datasources & report definitions</LI> <LI>user/role-based report authorization, container-based authentication</LI> <LI>column filtering & sorting, query by example</LI> <LI>no programming required to define complex, multistep database reports</LI> <LI>optionally using temporary tables</LI> <LI>expression language & field validation</LI> <LI>possibility to access non-SQL, 'Web Services' datasources</LI> <LI>fully customizable look & feel using CSS and XSLT</LI> <LI>flow control using XML and a ReST HTTP interface</LI></UL> xReporter is released under an Apache-style license, and we welcome contributions and patches as we try to grow this into a community-owned project. Currently, there is anonymous read-only cvs access and a downloadable tarball. There's a limited, live demo available on the project website, too. From: <A href="http://lists.xml.org/archives/xml-dev/">xml-dev</A> list</BLOCKQUOTE> I don't have a need for this right now, but... http://matt.blogs.it/entries/00001047.html Firefox not XSLT standards compliant? Sat, 07 May 2005 09:46:51 +0100 <a href="http://matt.blogs.it/topics/index.html" title="All Topics"><img style="padding: 10px;" align="right" border="0" src="http://matt.blogs.it/images/alltopics_clipping.jpg"></a>As I wrote yesterday, I'm now rendering <a href="http://matt.blogs.it/topics/adaptive-resonance-theory.xml">individual </a> <a href="http://matt.blogs.it/topics/trillian.xml">topic</a> <a href="http://matt.blogs.it/topics/rss.xml">feeds</a>. Each is a (slightly bare) RSS feed of posts on a particular topic. Taking slighly more than a leaf out of the <a href="http://www.feedburner.com/">FeedBurner</a> playbook each feed has an XSLT stylesheet which renders it for display in the browser. That way the same file that you can subscribe to in your aggregator can also do dual purpose as a cross-reference index of my blog. So far, so good. <a href="http://matt.blogs.it/topics/adaptive-resonance-theory.xml" title="A Topic"><img style="padding: 10px;" align="left" border="0" src="http://matt.blogs.it/images/topic_clipping.jpg"></a>What sucks is that, when you view a feed in FireFox, the HTML pokes through instead of being rendered as part of the page. I've spent some time this morning trying to figure it out and just couldn't seem to make it work. I called on <a href="http://www.docuverse.com/blog/donpark/">Don Park</a> who gave me some useful pointers. Then I made an interesting discovery. In both IE and XML-SPY the output from the StyleSheet appeared to be correct, i.e. the entities were decoded and the HTML took it's rightful place. Some hunting turned up a <a href="http://www.mozilla.org/projects/xslt/faq.html#d-o-e">FAQ on Mozilla XSLT</a> which seems to hold the answer: Mozilla's XSLT engine does not respect the <tt>disable-output-escaping</tt> option. They claim it causes trouble and I'm not in a position to disagree, however it also appears that this means Mozilla and FireFox aren't XSLT standards compliant which, if true, is both irritating and hypocritical because, as far as I can see, it's not an optional part of the standard. How is the Mozilla team picking and choosing which bits of the XSLT standard they choose to implement any different to situations in which other vendors do it, and get called on it? I'm not in a position to contribute to the Mozilla codebase or to look at this problem so it's unfair of me to gripe. Nevertheless I will. The reasons given are that it causes crashes and can slow down rendering. Both are reasonable first responses when pushing to get a 1.0 product out the door. But neither Mozilla nor FireFox are 1.0 products any more and these reasons don't stand up. Crashes can be solved (write better quality code) and, ultimately, judgements of rendering speed should be down to the user, not the developer. In short, I think it sucks. On a more practical note I really do want to see if I can figure out a way around this. I am a FireFox user and I care more about FireFox users than I do about IE users (for whom the feed renders properly, damnit!) Since I am generating the XML for the feeds myself is there perhaps another way of solving this? Some way of getting the HTML in the <tt><description></tt> field through XML validation but without requiring the entities to be unescaped in the XSLT? Any help you could give me would be much appreciated. http://matt.blogs.it/entries/00002555.html Must it always be this way? Tue, 10 May 2005 18:37:21 +0100 So today it's Apples turn to incur my mighty wrath. Having gone to hell and back solving all the browser related issues with XSLT rendering of RSS feed, <a href="http://www.bethlet.net/">Beth</a> dropped the bombshell that Safari 2.0 was completely ignoring my stylesheet and rendering the feed itself. Now, i'll grant you that Safari does a pretty good job rendering the RSS, it's <a href="http://matt.blogs.it/images/safari-rss.jpg">sweetly pretty</a>. However it rather pisses on my parade since Safari doesn't know a damn thing about <a href="http://matt.blogs.it/specs/ENT/1.0/">topics</a>! So i'm busy rendering up topic cross-references (major thanks to <a href="http://www.bethlet.net/">Beth</a> for solving what she said were simple XSLT problems but which, nevertheless, had me pulling my hair out) which Safari will happily ignore. Why does it have to be this way? Especially when I am actually telling Safari exactly what XSLT stylesheet it should be using. Can anyone supply me with the magic incantation to make Safari honour my stylesheet? http://matt.blogs.it/entries/00002571.html