> logical thing to create as the result of the process is an XML docume=
nt.
> To me, your question is equivalent to "Why can't my car producing pro=
duct
> take an XML document describing content, and an XSL describing the
> automobile to produce and generate the car?" Well, if XSL were an
> automobile producing language, that would make sense, but it isn't, i=
t is
> an XML producing language.
That's not to say of course that, if I am writing an XSL engine, I cann=
ot
provide a programatic object
interface that normally plugs in a "create XML output" widget, but whic=
h can if
desired plug in a "spit
out any danged thing you want" widget. In fact, it would be kind of cra=
zy to
write an XSL engine that
did not provide that kind of flexiblity, since it would provide as much=
"future
proofness" for the
maintainer of the product as it would for his/her customers.
Of course you have to write some code to take advantage of it, but it a=
lso
opens the door for pre-fab
(even pre-fab third party) widgets that spit out particular types of ou=
tput
given a few hints about the
desired attributes of the target output.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey@us.ibm.com
=