cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Date Fri, 05 Mar 2004 18:02:44 GMT
Alan wrote:
> * Daniel Fagerstrom <danielf@nada.kth.se> [2004-02-23 15:21]:
<snip/>
>>XSLT
>>====
> 
> 
>>A MomentoSource would also give a good way to use Momento together with 
>>XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of 
>>sources somewhat, let me explain:
> 
> 
>>The Source interface provides a getInputStream method, in Cocoon some 
>>Sources implements org.apache.excalibur.xml.sax.XMLizable that provides 
>>a toSAX method as well. SAX or Streams are probably not the most 
>>efficient way to communicate with an XML db, so to make the pseudo 
>>protocol idea usable together with Momento, we should provide a way to 
>>get a DOM structure from a pseudo protocol. This could be done by 
>>introducing a new interface:
> 
> 
>>interface DOMizable {
>>   org.w3c.domNode getNode();
>>}
> 
> 
> Momento, with Cocoon in mind, lends itself to streaming.
> 
> Momento would readily support a read-only W3 DOM, but a read write
>     W3 DOM is quite ugly.
>     
>     W3 DOM lets you to create inconsistant documents, with is not in
>     keeping with the C in ACID. (Examples if you want them.) There
>     is no way to specify the start and end of an atomic transcation
>     through the DOM API.
> 
> Momento uses XUpdate since one can specify a set of modifications,
>     and Momento can process those modifications as an atomic
>     transcation. XUpdate expresses all document modifications, and
>     does so declaratively. Momento can then make logic of you
>     intentions.
> 
>     In a pipeline, XML input can be transformed into XUpdate
>     statement. I suppose one could an XUpdate using JXTemplate from
>     Flow as well.
> 
>     XUpdate is really the method of choice for updating Momento.
>     Both XUpdate and SAX input are a good way to get data into
>     Momento.
> 
> I don't know if you and I talking about the same thing here, but
>     the sight of org.w3c.domNode leaves me cold. It is a nice
>     in-memory interface, but a poor interface for persistence.
> 
>     If W3 DOM were the way to modify a Momento document, the
>     application developer would have to be prepared to catch all
>     kinda hel.., er, exceptions, since there are a bunch of stupid
>     things that Momento won't allow.

I only talked about read only access of DOM documents from XSLT, don't 
worry ;)

> 
> 
>>or something similar. If the MomentoSource implements DOMizable, we have 
>>direct access to nodes in the XML db.
> 
> 
>>Now we are prepared to connect Momento to XSLT. In Cocoon we can use 
>>Saxon through the org.apache.cocoon.transformation.TraxTransformer, you 
>>just need to change cocoon.xconf a little bit to use Saxon instead of 
>>Xalan. There is also a TraxGenerator in the scratchpad that could be 
>>used with some small modifications.
> 
> 
> Momento connects to XSLT using a Saxon NodeInfo interface. It could
>     connect to Xalan just as easily (through read-only W3 DOM?).

Yes, that the idea. It can connect to Saxon through read only DOM as 
well, don't know if there are any drawbacks with this though.

>>I would guess that Momento mainly would be accessed through the document 
>>function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the 
>>transformerand the URLs in the document functions are resolved by using 
>>an implementation of javax.xml.transform.URIResolver that is provided by 
>>the TraxTransformer.
> 
> 
> The above is somewhat confusing for me. Momento does support the
>     JAXP API. XUpdate is implemented as a SAX filter. It seems like
>     Momento would work nicely in as a source, sink, or filter for
>     SAX events.
>     
>     I've imagined that a pipeline would start with a Momento
>     document and an XSLT trasform or XQuery query.
> 
>     Something along these lines:
>     
>         <map:match pattern="index.html">
>           <map:generate type="momento" src="momento.mx"
>                                        xslt="index-document.xslt"/>
>           <map:transform type="xslt" src="document-to-web.xslt"/>
>           <map:serialize type="html"/>
>         </map:match>
> 
>     (It is easier for me to express myself as a Cocoon user.)

I rather propose:

<map:match pattern="index.html">
   <map:generate type="xslt" src="momento:mydocument.mx"
                 xslt="index-document.xslt"/>
   <map:transform type="xslt" src="document-to-web.xslt"/>
   <map:serialize type="html"/>
</map:match>

The idea is that the xslt generator can be used with any source. For 
this to be efficient with Momento we must organize so that the XSLT 
processor can access momento as a read-only DOM. This will not happen 
today in Cocoon. So what I describe is how to extend the involved 
mechanisms in Cocoon so that Momento get DOM as input.

This is done by creating a new interface, let us call it 
ReadOnlyDOMizable to avoid confusion ;) so that we can check if a 
source, (e.g. the Momento source), can return a DOM. We also need to 
extend the URIResolver in the XSLT processor implementation so that it 
returns a DOMSource if the input source implements ReadOnlyDOMizable, 
SAXSource, if the input source implements XMLizable and StreamSource 
othewise. That is all.

> 
>>The implementation of the URIResolver that is used is 
>>org.apache.excalibur.xml.xslt.XSLTProcessorImpl in its current 
>>incarnation it uses the exclaibur source resolver to get the source and 
>>then it returns a javax.xml.transform.stream.StreamSource. For use with 
>>Momento we need an implemetation of URIResolver that checks if the the 
>>source is DOMIzable and in that case returns a 
>>javax.xml.transform.dom.DOMSource instead. This can be done by extending 
>>the excalibur XSLTProcessorImpl and change the XSLTProcessor in 
>>cocoon.xconf.
> 
> 
> Okay, at this point I think the problem might be that you are
>     thinking:
> 
>         Momento == DOM
> 
>     Where as I think:
> 
>                     Momento 
>                       |
>       +-----------+---+------+--------+--------+
>       |           |          |        |        |
>     W3 DOM      Saxon       SAX     Xalan   XUpdate

I don't, but I think it is efficient to view it as a read only DOM when 
you want to use XSLT (or XQuery) as a query language for Momento through 
JAXP.

>>XQuery
>>======
> 
> 
>>XQuery in Saxon use a propertary api, (there are no standard in this 
>>area yet). So we need a specialized SaxonXQueryGenerator. Saxon use the 
>>JAXP URIResolver for XQuery also, so the above described mechanisms can 
>>be used here as well. Unfortionatly Saxon is MPL 1.0 that is not 
>>compatible with ASL, so we cannot have Saxon as a part of Cocoon :(
> 
> 
> I am very interested in seeing XQuery become a a first class citizen
>     in Cocoon. If Saxon cannot be part of Cocoon and somehow Momento
>     can be part of Cocoon, it might be enough to make Saxon pluggable.
> 
>     I'm really enjoying working with Saxon.

That is the idea for the integration strategy that I propose, all 
integration is done at the Jaxp level, so you can use whatether Jaxp 
compliant processor together with Momento. Then you can plug in Saxon as 
described in http://wiki.cocoondev.org/Wiki.jsp?page=Saxon. For XQuery 
the situation is a little bit worse as I described above, as part of the 
Saxon implementation of XQuery use things outside Jaxp. We have some 
blocks e.g. ojb and web3 that use special mock interfaces for making the 
code compilable even if the needed jar not is provided. Maybe this 
strategy could be used for the Saxon specific api:s that would be needed 
for implementing a XQuery geneerator. I don't know enough about MPL 1.0 
to know if it is allowed though. For GPL you are not even allowed to use 
mock interfaces IIRC.

/Daniel

Mime
View raw message