There is a lot to respond to here, so I shall do so inline:
On Jan 16, 2008 8:43 PM, Abel Braaksma <abel(_dot_)online(_at_)xs4all(_dot_)nl>
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(_dot_)bologna(_at_)gmail(_dot_)com> 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(_at_)dykman(_dot_)org
--
- though a program be but three lines long
- someday it will have to be maintained.
--~------------------------------------------------------------------
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>
--~--