> Monsieur, bien le bonjour, There appears to be quite a few french-speaking people here. Que diriez-vous de parler fran�ais pour agacer les autres participants ? :-)
> I'm not an XPS guy but I'm sure there could be interest. What I don't > understand exactly is what you mean by "sharing the engine". Well, "engine" is maybe a bit of a mouthful here. The XML::XPathScript manpage provides a source file syntax and a few functions to call from within said source file. The corresponding implementation code (parser and functions) should be implemented in a way that allows for calling both from /usr/bin/xpathscript and the A::A::L::XPS used as a mod_perl handler, whatever technical solution we use to acheive this result (the current XML/XPathScript.pm was copied-and-modified from A::A::L::XPS by Matt and this is of course a Bad Thing). This should hold for subsequent changes too; this is why I did not propose something like XSLT's multi-file output (this notion does not fit with the AxKit pipeline model and can be emulated with other means). > I would be. I've been toying for the longuest time about > twinking the A::A::L::XPS module so that it can (a) be used > both online and offline and (b) to use the faster libXML. > So far I've resisted the urge, but if someone else is > also interested into tinkering into the belly of the beast, > I'm all for lending a hand to the project. Great! See proposed roadmap at the bottom of this message :-) > >>IIRC Matt has started on that but bumped into issues (XML::XPath and > >>XML::LibXML have different worldviews, mostly because the former uses the > >>XPath OM and the latter the DOM). It may be that his old patches in that > >>direction were close enough that they can be worked on easily. I speak without looking at Matt's efforts first, which admittedly is a Bad Thing too - but sticking to just the XPathScript documentation at http://axkit.org/docs/xpathscript/guide.dkb we could live without merging the object models. One doesn't need to do any method calls on the underlying node objects because the findvalue() function suffices to make stylesheets, iff the result value stringifies properly in Perl (this is (almost) the case in XML::XPath). This raises the question of how much we should try to be upward-compatible in XPathScript. There are a few things (like the aforementionned apply_templates() semantics) that I would like to change, so maybe we should do ``use XML::XPathScript "1.0";'' to request the new semantics, and keep the old behavior if the stylesheet does not do this. I propose we strive to keep the XML::XPathScript unit tests working, but break all what we want in use "1.0" mode. I propose the following roadmap (I can promise no specific schedule :-): Phase 0: reverse-engineer and document the XPathScript API At this stage we should investigate all differences between A::A::L::XPS and X::X (as I call them for the rest of this message), and decide whether they are enhancements of either side (e.g. the ``new'' method in X::X makes things OO, but the rest of the diffs is likely to be more up-to-date in the AxKit version because X::X is not maintained), stuff that only belong to the AxKit framework, or real behaviour differences (there are only a few). => deliverable: a POD for all global variables and functions defined in any of the modules, with footnotes inside that explain how this is done differently in X::X if needed. Mere enhancements are to be documented only once (e.g. if the two functions have a similar duty, but one of the two does it better than the other, we just document the best performing of the two). Phase 1: make A::A::L::XPS a subclass of XML::XPathScript. Migrate all code into X::X, keeping the test suites running, intermingle the POD of phase 0 so that each function is near its doc (I happen to love this style of POD :-). Split all variant behaviour into method callbacks (e.g. provide a ->debug() that warn()s in the base class implementation but will AxKit::Debug() in A::A::L::XPS; provide a ->uri2file() method to factorize both implementations of XML::XPath::Function::document in the same way, etc). Revert to eval/die error handling in X::X instead of the OO variant for portability (the two are interoperable, the syntax is only more awkward). Turn A::A::L::XPS into a subclass, with only the specific code (Apache handler, axkit: URI management, etc.) as class overloads of the appropriate hooks placed in X::X. => deliverables: a big XML::XPathScript module (version 0.04) and a much smaller A::A::L::XPS, to be submitted to Matt for review, and then uploaded resp. to CPAN and to a new release of AxKit. Phase 2: hack away ! Do the ``use XML::XPathScript 1.0'' trick, and re-plan the enhancements we want (starting with XML::libXML maybe). Code them, test them, release them. => deliverable: a whole new powerful XML::XPathScript 1.0. Phase 0 can be parallelized between someone who groks AxKit (Yanick ?) and someone who only groks XPathScript (me). How about starting right now? ;-) -- Dominique QUATRAVAUX Ing�nieur d�veloppeur senior 01 44 42 00 08 IDEALX --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
