Hello,
I do a lot of processing using XSLT. I take the XML file with only
data, and transform it into an XSL:FO file with VERY complex
formatting.
I wouldn't need to generate the XML, because all the data comes from a
database. The XML is just a convenient easy-to-do representation that
is then passed to the XSLT where the real formatting processing
occurs.
XSTL does the job but has a very wordy syntax and lack some functions
that you would normally espect in any programming languages. It is
good for doing basic things like restructuring XML, but if you want to
do more complex calculations, like automatically calculating the
column widhts of an XSL:FO-table you are generating you will soon
notice the limitations of the language.
So where is the ideal solution? I would want something with the power
of XSLT to manipulate and access XML but at the same time having more
functionality, like any programming language.
Note also that the step of generating XML is not mandatory, although
probably it is hard to make it easier. The alternative would be to
generate the whole data structure in an object.
The whole process is done in Java. That is I generate the XML through
Java and then call Xalan(XSLT processor).
Thanks for any feedback...
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> Hello,
>
> I do a lot of processing using XSLT. I take the XML file with only
> data, and transform it into an XSL:FO file with VERY complex
> formatting.
> I wouldn't need to generate the XML, because all the data comes from a
> database. The XML is just a convenient easy-to-do representation that
> is then passed to the XSLT where the real formatting processing
> occurs.
Maybe you should check out the Cells project by Kenny Tilton. I think
he's using it to create very complex documents.
From: Kenny Tilton
Subject: Re: Replacing XSLT? Any suggestions? Help please.
Date:
Message-ID: <3DDCFE28.9080309@nyc.rr.com>
Fernando wrote:
> ·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
>
>>Hello,
>>
>>I do a lot of processing using XSLT. I take the XML file with only
>>data, and transform it into an XSL:FO file with VERY complex
>>formatting.
>>I wouldn't need to generate the XML, because all the data comes from a
>>database. The XML is just a convenient easy-to-do representation that
>>is then passed to the XSLT where the real formatting processing
>>occurs.
>
>
> Maybe you should check out the Cells project by Kenny Tilton. I think
> he's using it to create very complex documents.
yeah, in the clinisys app I /did/ do just-enough html parsing so i could
prepare text-heavy documents (using a teeny subset of html) in html,
then have the app parse the html at runtime to create a set of widgets
which arranged themselves neatly.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
From: Howard Stearns
Subject: Re: Replacing XSLT? Any suggestions? Help please.
Date:
Message-ID: <3DDC49DA.8040506@attbi.com>
Oleg Kiselyov has a scheme library called sxslt:
http://www.international-lisp-conference.org/Speakers/Presenting/Oleg-Kiselyov.html
http://library.readscheme.org/pagexml.html
As I understand it, you can use your existing XSL, or put it into an
s-expression form from which you can also include scheme code. It looks
pretty neat, though I haven't used it.
I don't enjoy the pattern-matching/query-language style necessary in
writing XSLT. Getting it to do what I want always seems like such a
puzzle. Who has time for that? And debugging? Ugh!
I have a much easier time with the presentation model from CLIM: I
create instances of appropriate types for each element in the input
file. (This can be a full, in-memory, DOM-like model, or sometimes I
throw the instances away when I'm done, in a SAX style.) Then I write
generic functions (or presentation methods) for the different kinds of
element types, in various views as needed (e.g., for an element in
context/view A or context/view B). Since the elements and views both
have multiple inheritance, I only have to write a very few
presentation-methods where I would normally have to write a LOT of XSLT.
Sometimes I make use of :around methods. As I understand it, this is
what multi-method dispatch was invented for, and it's really good at it.
Ironically, I have used this approach in a more Java-like, but not
Common Lisp. The time it takes to implement multi-method dispatch in
Java-like languages isn't that long, and it's worth it on the first
project. Alas, if the Java-like language doesn't have macros, then
defining the methods in application code can get pretty verbose. But at
least you don't need many, and it's just cut/paste/edit.
By the way, if you're used to thinking this way, but need to keep
everything in XSLT, there's a very clever technique for inheritance of
XSLT rules that was worked out by the Darwin/DITA group at IBM. I love
this! CLOS works by having a flat list of all the superclasses for a
given instance. Well, a DTD let's you define default attribute values
for elements of a given type. So in the DTD, you specify a default
class-precedence-list attribute for each element, whose value is a list
of "supertype" elements. Then you write your XSLT patterns to match
elements that have a given substring in the class-precedence-list
attribute value. (Multiple inheritance and ordering among classes is an
exercise to the reader...)
Another approach I've used is to generate several steps of XSLT
transformation. I try to keep all the steps except the last as semantic
manipulations of data and metadata (attributes, references, and such),
and then do the formatting at the end. This was for big files that blew
the limits on the Xalan processor. It also made each XSLT file more
manageable.
One area that I was never satisfied with was with the FO processing. I
found the free FO rendererers (e.g., FO->PDF) to be kinda buggy and
slow, and I ended up learning more about TeX than I really wanted to.
Regards,
Howard
thelifter wrote:
> Hello,
>
> I do a lot of processing using XSLT. I take the XML file with only
> data, and transform it into an XSL:FO file with VERY complex
> formatting.
> I wouldn't need to generate the XML, because all the data comes from a
> database. The XML is just a convenient easy-to-do representation that
> is then passed to the XSLT where the real formatting processing
> occurs.
>
> XSTL does the job but has a very wordy syntax and lack some functions
> that you would normally espect in any programming languages. It is
> good for doing basic things like restructuring XML, but if you want to
> do more complex calculations, like automatically calculating the
> column widhts of an XSL:FO-table you are generating you will soon
> notice the limitations of the language.
>
> So where is the ideal solution? I would want something with the power
> of XSLT to manipulate and access XML but at the same time having more
> functionality, like any programming language.
>
> Note also that the step of generating XML is not mandatory, although
> probably it is hard to make it easier. The alternative would be to
> generate the whole data structure in an object.
>
> The whole process is done in Java. That is I generate the XML through
> Java and then call Xalan(XSLT processor).
>
> Thanks for any feedback...
> I have a much easier time with the presentation model from CLIM: I
> create instances of appropriate types for each element in the input
> file. (This can be a full, in-memory, DOM-like model, or sometimes I
that's an excellent writeup. could you please share some code?
(Probably not.)
It would be wonderful if you/someone could post an example of this
kind of transformation *without* using XML/XSLT...
jls
From: Howard Stearns
Subject: Re: Replacing XSLT? Any suggestions? Help please.
Date:
Message-ID: <3DDD1EF5.9030602@attbi.com>
Jules F. Grosse wrote:
>>I have a much easier time with the presentation model from CLIM: I
>>create instances of appropriate types for each element in the input
>>file. (This can be a full, in-memory, DOM-like model, or sometimes I
>
>
> that's an excellent writeup. could you please share some code?
> (Probably not.)
Well, the code was in Curl, not Common Lisp.
I've posted separately (subject: personal internet proxy?) that I'm now
trying to experiment with modular ways of defining transformations and
side effects for content that come through a proxy. I expect that I'll
be using these presentation-method sorts of techniques for that, and
I'll probably post something if I ever get anywhere with it. It's low on
my priority list.
>
> It would be wonderful if you/someone could post an example of this
> kind of transformation *without* using XML/XSLT...
>
> jls
Using Curl, I defined XML elements like these for XHTML. I apologize
for the mixing of different (meta-)syntactical conventions involved
(e.g., different capitalization styles):
;; Defines the default namespace for the following elements.
{define-namespace "http://www.w3.org/1999/xhtml"}
;; Division is defined by the core system, called siteworks.
;; So xhtml:html behaves like a siteworks:Division.
{define-element public html {Division}}
;; An xhtml:head is a kind of Block-Element...
{define-element public head {Block-Element}}
;; ... but it presents graphically within siteworks as nothing.
;; The funny colon stuff is the way siteworks does type declarations.
;; You can think of this as being like:
;; (define-method present ((view Standard-View)
;; (resource head)
;; (context t))
;; nil)
{define-method {present view::Standard-View, r::head, context}
null}
{define-element public title {Title}}
{define-element public body {Block-Element}}
{define-element public h1 {Title}}
{define-element public p {Block-Element}}
;; etc....
The Standard-View for all these was to produce some reasonably handsome
graphical rendering in the browser, using the Curl primitives. Other
views produced various kinds of XML or even Curl source code.
Siteworks had a file reading operation that used a SAX parser to
instantiate the approriate element and attribute instances. (Lots of
issues here about namespaces, SAX vs DOM, integration of element types
with the host language type system, etc. But through the magic of
macros, none of this shows up in the application code we see here.)
;; For another doctype, I created a HEAD element that behaved
;; a little differently than a normal siteworks:Title element:
{define-element HEAD {Title}}
;; The use of finalize instead of present would probably be unecessary
;; if I remodularized the core of siteworks, and especially if I
;; implemented :around methods.
{define-method {finalize view:any,
args:Arguments,
r::HEAD}
;; The returned result here is a Curl graphical object, not XML.
;; (That is, {heading ......} is how you create a Curl graphical
;; heading within the browser.)
;; It could just as easily have been someting more like:
;; (pprint `(heading :color "#4C004C" :font-family "sans-serif"
;; ,@args))
;; *the-xml-output-stream*)
;; or whatever X/HTML generation style you like from CL-HTTP
;; or Allegroserve, etc.
{heading color="#4C004C",
font-family="sans-serif", {splice args}
}
}
The point is that you just define the element type inheritance in a
declarative style. Less often, you also define methods that cover what
is _different_ about certain elements in certain contexts.
I'm happy to discuss the past or present work at higher bandwidth.
Howard Stearns
1-781-477-1930 (US east coast)
http://www.stearnsfamily.org/howard
On 20 Nov 2002, thelifter wrote:
[snip]
> So where is the ideal solution? I would want something with the power
> of XSLT to manipulate and access XML but at the same time having more
> functionality, like any programming language.
There's always SXML and SXSLT, which are Sexprs varients of XML and XSLT
(including an Sexpr XPath). Currently, there are only parsers/processors
written in and for Scheme, but I imagine a Common Lisp version wouldn't be
too terrible hard to build.
The really nice bit is that you can use all your normal Lisp tree
structure manipulation techniques in the normal way *and* use your legacy
XSLT (for the most part). Plus, things are much more tightly integrated
with the host langauge, so, for example, you can make your 'Path
expressions functions which specialize depending on context.
I keep thinking that SXML will be the wedge that shows XMLers just how
much better things can be.
Note that SXML is designed to be closer to XML (and XSLT) than many of the
alternative markup languages sketched in this group. I think this is a
virtue of it as it's more designed for people who've worked themselves
into a state of XML comfort. Think of it as Steps 2-4 of the 12 step
plan...
> Note also that the step of generating XML is not mandatory, although
> probably it is hard to make it easier. The alternative would be to
> generate the whole data structure in an object.
[snip]
The SXML toolkit includes XML parsing and generation, so you can hide what
the lisp hand is doing from the Right(tm) hand (and vice versa).
See:
http://okmij.org/ftp/Scheme/SXML.html
http://okmij.org/ftp/Scheme/xml.html
Cheers,
Bijan Parsia.