AW: [Xml-compile] Using the DOM built by the toolkit

[Michael Ludwig]

> Von: Mark Overmeer
> * Michael Ludwig (m.ludwig at epages.com) [120220 11:01]:

> > Well, the need is to get an HTML report of the data I receive via the
> > web service. The best way to produce one from XML is to apply an XSL
> > transformation. This is done using libxslt, the companion library to
> > libxml2. The Perl interface is XML::LibXSLT, and it works very well.
> > You need to supply a libxml2 DOM as input to the transformation.
> 
> SOAP is an interface, both client and server should use an abstraction
> layer for presentation to be able to change the interface without
> changing/breaking the core client application/ user experience.

Guess you mean *protocol*, not *interface*. Anyway, getting your point.

> XML::Compile contributes to the abstraction layer providing a HASH which
> contains the message data.  Then, you can use a template to display
> it to the user.  What I read in you explanation, it that you only want
> to use the transport mechanism, because XSLT provides the abstraction.

Well, yes. As an experienced user of XSLT, for producing HTML from XML,
I vastly prefer XSLT over Perl hashes. Same for XML to XML. Other scenarios,
probably not.

> It's a bit odd to put queries in Perl, and process the answers directly
> with XSLT.  As first idea, it may work... but when thinking about
> character-sets, error handling, validation... arggghhh, frightens me
> a lot.  Of course, it is your choice (and burden)

Can't see how it would be frightening. I receive both the data in the
hashtable and the DOM, so I can check the data for errors, and then go
on to produce the report using the DOM if there are none. And the XSLT
program could of course be written to make sense of errors in the XML
and show the errors in the report. Character sets are no problem at all
using XSLT. Best of both worlds, really.

> > And what about adding an accessor for the DOM?
> >   $obj->dom         # new!
> 
> Of course.   $trace->responseDOM
> 
> I do not believe your solution is sound on the long run, but it does
> add something useful to the trace without measurable expense.  I'll
> send you an intermediate version of the module, to test.

Worked fine, as reported. Thank you!

Michael