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>
|
- [xsl] Announcement: Dexter - XSL Transform Generation Tool, Michael Dykman
- RE: [xsl] Announcement: Dexter - XSL Transform Generation Tool, Bjorndahl, Brad
- Re: [xsl] Announcement: Dexter - XSL Transform Generation Tool, Michael Dykman
- Message not available
- Re: [xsl] Announcement: Dexter - XSL Transform Generation Tool, Michael Dykman
- RE: [xsl] Announcement: Dexter - XSL Transform Generation Tool, Chaudhary, Harsh
- [xsl] XSLT - How to find the last element in a group of nodes inside of a for loop, Chaudhary, Harsh
- [xsl] RE: XSLT - How to find the last element in a group of nodes inside of a for loop, Wei, Alice J.
- Message not available
- [xsl] regex and tab-delimited text, Terry Ofner
- Re: [xsl] regex and tab-delimited text, Jesper Tverskov
- Re: [xsl] regex and tab-delimited text, Terry Ofner
|
|
|