[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ozone+XML: what do users want?



> 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.

(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.)

So, the really tough question is:  does efficiency matter anymore (esp.
w.r.t. to pure Java)?

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.

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?

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?

5)  Do you expect to use the XML or servlet features of
Ozone, at all?

Comments greatly appreciated.

Best Wishes,

Ann Tecklenburg