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

Re: Ozone+XML: what do users want?



On Mon, 22 Nov 1999, 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).
Yes, it's absolutely needed to put basic access path to the DOM (XPath,
XQL...) in the server to get "acceptable" performance.

> 
> 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 ..
I don't know... Java is slow, yes. Today, ozoneXML is even slower. We should
try to get something working. Then get it working on max speed that java and
our main architecture allows. When we start using C++, we loose much of the pure
Java advantages - and the focus of the ozone project.

> 
> > 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?
We want to use it as document storage/management system with and without
servlets.

Also, using the ozoneXML stuff it should be possible for us to represent
database content (XML and non-XML) as DOM/XML, as discussed earlier. (XML
query/manipulation tools as ad-hoc tools for ozone in general)


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de