[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone+XML: what do users want?
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