[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone+XML: what do users want?
wow!!!, so many spelling mistakes !
sorry. next time I'll check before posting :)
Regards
Zvi
Zvi Avraham wrote:
> Hi
>
> Ann Tecklenburg wrote:
>
> > > ozone as cache backend for cocoon? We tried this already with
> > > less success.
> > >
> >
> > Yes, I doubt that an efficient implementation
> > of XML Document+XPath engine can come from in a loosely-coupled,
> > external framework:
> > I suspect that the XPath statement must be pre-processed and
> > storage-coupled to its
> > Document similar to the way that a high-performance RDBMS "binds" SQL
> > queries against the
> > target tables.
>
> right (in my understanding both XPath query (XQL in the future), XSLT, and
> XML Update engines will be embedded into Ozone DB Server (Ozone Database
> object methods is analog of Stored Procedures in RDBMS world, and each one
> executed inside transaction).
>
> I think XPath query compilation (and XSLT stylesheet compilation also), is
> very usefull, as well as a lots of other possible speed-ups, but it can
> wait, until we will have at least "interpreted" XPath query engine inside
> Ozone ...
>
> > (In explanantion: XPath statements are "selections" only, XSL is
> > selection formatting. XSLT=XSL+XPath. If you are doing only XSLT for
> > servlets,
> > transactions are useless because the data stored in the server does not
> > change.)
>
> I think u missunderstand XSL term :)
> XPath is part of XSLT, and XSLT itself is part of XSL spec, which also
> describe XSL:FO.
>
> For me doing XSLT processing in Servlet engine is good only for load
> balancing
> (multiple Servlet Engines free XML DB from doing lot of XSLT)
>
> > So, the really tough question is: does efficiency matter anymore (esp.
> > w.r.t. to pure Java)?
>
> always,
> but the rule is: do optimizations after you have something working :)
>
> Look at xml.apache.org, it's enclude also C++ versions of XML Parser and
> XSLT processor, maybe we can work with them using JNI ..
>
> > Or will flexibility, ease of use, and time-to-market win out? What are
> > the advantages of
> > being able to run-time select the XML Parser, XPath and XSL processors
> > engines?
> > The disadvantages?
> >
> > This is extremely important because
> > it will be a world-class effort to do a highly optimized, tightly
> > coupled Document+
> > XPath+XSLT storage engine.
>
> look at eXcelon, this is native XML DB Server,
> with built-in _native_ XQL, XPath and XSLT engines.
>
> > So we need to know:
> >
> > 1) How do you expect to use Ozone+XML?
> >
> > 2) What can you live without or get from another product?
>
> I planning to use eXcelon in high-end version (which will be very expensive
> b/c eXcelon cost 15K per CPU) and OzoneXML in low-end version of the same
> product (of course it's not easy, I still need to figure out how to make the
> same codebase work with both :)
>
> > 3) What features do you *require* from Ozone+XML
> > if you use the combination at all?
> >
> > 4) Will you primarily use Ozone+XML as a XML Document storage
> > engine for servlets?
>
> yes
>
> > 5) Do you expect to use the XML or servlet features of
> > Ozone, at all?
>
> Ozone have not servlet features,
> anyway servlet (or HTTP/URL/Cocoon - choose one) is not the core of Ozone,
> it's just one usefull utility.
> My OzoneProducer is just a draft and don't take it as real-life code ...
>
> > Comments greatly appreciated.
> >
> > Best Wishes,
> >
> > Ann Tecklenburg