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

["Michael Dykman" <mdykman@xxxxxxxxx>]

There is a lot to respond to here, so I shall do so inline:


On Jan 16, 2008 8:43 PM, Abel Braaksma <abel.online@xxxxxxxxx> wrote:
....

> 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


Thank you, thank you, thank you.  This is precisely it.  You were able
to phrase it
much more concisely than I was.  Thank you.


> 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)

Sorry about the version confusion, entirely my fault.  Apparently, while I was
generating 1.5 compliant code, I was inadvertently using 1.6-specific library
calls, all of which can be worked around when I have the time. I would like to
make it backwards compatible to 1.5 at least, and the library ultimately
should be usable even in 1.4 with an external parser.

> 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!

Fair enough..  I'll take this into account in the next revision, probably
this weekend.  Mostly documentation improvements.

Abel: would you mind if I borrowed some of your verbiage for that documentation?

> 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!

Noted.  That is something I am aiming for in version 2.  I was anxious
to get the
idea out of head and that is one of the decisions I made early on just to get a
working model.  The namespace would be a welcome addition.

> 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.



On Jan 17, 2008 12:22 AM, Alessandro Bologna
<alessandro.bologna@xxxxxxxxx> wrote:
> I do have a question, if you don't mind. Why did you choose to
> generate the XSLT from the template in Java, instead of XSLT? After
> all, that's one thing that XSLT can do well. And, is that the reason
> why you avoided using a namespace for your decorators? I mean,
> sometimes handling properly namespaces is quite some extra work in
> Java, but not really in XSLT...

You know, it never occurred to me until I read this.  That is an
excellent idea and bears
some thought.  I chose Java because I am intimate with it's XML
facilities and there is a
lot of logical transformation going on under the covers which is more readily
accomplished with a general purpose language.  I suspect that I could
simplify some of
that now; when I began implementation, I was still not sure when I was
going with this :-)


I trust no one minds if I make periodic release announcements to this list?


 - michael dykman
 - michael@xxxxxxxxxx
 --
 - though a program be but three lines long
 - someday it will have to be maintained.