[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