xsl-list
[Top] [All Lists]

Re: [xsl] Announcement: Dexter - XSL Transform Generation Tool

2008-01-16 18:44:21
Steven Ericsson-Zenith wrote:

I'm still a little confused and this is mainly because of the generalized cases you keep alluding to.

The tool will convert html pages into an XML file that contains the content and its structure and will also produce an XSLT file. Is that correct? The "arbitrary data" is the content of such pages.

Most html pages are not well-formed XML. What am I missing?


I think Dexter suffers a bit from what many xml/xslt related projects suffer from: there's no clue for the reader what the input is, what the output is, where the XSLT processor comes into play and where the Dexter engine comes into play.

However, when you read the rather lengthy user guide, I think the explanations and the terminology are quite well explained (and is itself build with Dexter), search for "design document": http://dexter-xsl.googlecode.com/svn/trunk/docs/dexter-user-guide.xml

From my point of view (very possibly not Michael Dykman's, but I'm just trying to help here) you could compare it a bit to what annotations are to Java, what XmlBeans do to convert XML to classes (regardless of language), what aspect oriented programming could be to any language. However, Dexter reverses the process, instead of annotating the source code, he annotates the result and then goes back:

1. you take any possible output (i.e., a design XHTML file from your design company), 2. you annotate it (in plain English: at a H1 tag you put an annotation for "this tag must be filled with anything that's in /*/my:Caption")
  3. you run Dexter on it, result: XSLT file
4. you take your original source XML (the one that holds /*/my:Caption and the likes) and this Dexter's XSLT file 5. run these two with your favorite XSLT processor (in the example XMLs like http://dexter-xsl.googlecode.com/svn/trunk/docs/dexter-api.xml you see that the author use the xml-stylesheet PI for that purpose) 6. output is the same as your input (nr 1 above) but now filled with the right content from your source XML

This seems like a very useful tool for me and I can think of many possible applications for it. I wanted to try a minimal example for myself to test the scenario sketched above, but I couldn't because I can't run it. The offending bit being that in your documentation you say "Dexter requires a minimum Java JRE 1.5." (I think you mean "at a minimum"), but this is not true, you use Java 1.6 statements, like java.util.Arrays.copyOfRange, which will throw a NoSuchMethodError when you run your JAR file with Java 1.5 (and I haven't upgraded yet, will do so later to try your thing)

A note about the documentation, especially http://dexter-xsl.googlecode.com/svn/trunk/docs/dexter-user-guide.xml: I think it would be clearer for many to give with each 'keyword' a possible design document, a possible input, and a possible result, in a way that it really matches (because, using a phrase like "might produce this..." does not give much hope for a stable product). These three document snippets should not be presented as one snippet (as is now the case, you combine them), but as three separate snippets with a descriptive header to each of them. It took me a few minutes before I understood how to read the examples and it still often puzzles me. Examples do a lot to people: before reading the text, people try to grasp the example!

Another note, but now about the design of your product. Though it looks like a well thought-of design, I think you made one major mistake not to go the W3C XML way to write extensions in their own namespace. This has been a best practice since about a 10 years or so, and not doing so invalidates many documents (your own example design documents become invalid XHTML because no extension attributes are used for the dexterity attributes). For me, that alone would be a reason not to use your tool, but otherwise it looks like something I've been looking for for a long time!

A note in general: few projects that have a first-off or a first beta have such extended documentation, including a full API documentation! My compliments. It will take some time from here to full usability, but it seems to be a way to put XSLT to steroids for simple, documentation-like use-cases.

Hope to see more of your project in due time, and please inform me when you have a Java 1.5 version ready (or when you plan not to have it ready and stick to 1.6).

Cheers,
-- Abel Braaksma



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>