[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: XML Server
Falko Braeutigam wrote:
> On Tue, 26 Oct 1999, Ann Tecklenburg wrote:
> > I have checked out the mail archives, etc. on this project:
> >
> > It would be nice if somebody would write an "ideal" XML server,
> > but I don't think this will be the one.
> >
> > IMHO, SQL is the *wrong* choice for a QL for XML and
> This one is clear ;)
agree
> But there is a small"but". SoftwareAG, a german database company, has been
> providing its database software for 20+ years I think. So they seem to be very
> experienced with database development. They never started an OODBMS - but the
> _have_ a XML server called tamino. (somewhere at http://www.softwareag.com)
> So SQL is indeed the wrong choice but maybe not the whole relational thing.
Falko, you are wrong here, Software AG flagship product is ADABAS - the most
famous HIERARCHICAL database - father (or mother ?:) of modern OODBMS. In fact
Tamino have 2 database engines - X-Machine(native XML storage - PDOM) and SQL
engine, also they have module, which allows view of relational data as XML, called
- "X-Node". You can query XMl content in Tamino using XQL or work using Java DOM
API ...
> Don't get me wrong, we are here to make a pure OO, pure Java database! ;)
Somebody can explain me, why Germany have so many good database companies ?
Software AG, POET and Ozone :-) !
> > the W3C seems to agree here, and they have IMHO a poor
> > design for their engine. They appear to be *not*
> > interested in Java, but in C++.
> As far as I see, most of the w3c specs depend on Java.Is there any chance to a
> C++ based XML server whatever?
sure native server will be faster,
but if your client is Java-based, then you have some benefit when working with
Java-based server (avoiding layers).
Also you can easily embed Java-based Ozone into your application / servlet
(LocalDatabase vs. RemoteDatabase).
> > Also, I checked out the dbXML project: its barely gotten
> > started and is also in C++.
> >
> > The whole Apache.org effort is much more interesting.
> Perfectly agree in general. But in the Cocoon (Java Apache Web publishing
> framework) mailing list there is a discussion about a "XML repository". Today
> cocoon is DOM based but they decided to use SAX instead of DOM to be able to
> handle huge documents on small computers. In other words: provide a scalable
> solution. To mee it seems that they do not believe that something like a
> persistent DOM can be done. I known this cannot be the reason but I got this
> impression.
>
> Zvi is a member of the cocoon list and is more experienced with cocoon than
> me. Zvi, can you clarify this a bit?
Hannes Haug, from Cocoon list and he also PDOM proponent (as I understand).
I was trying to convince Stefano to leave DOM API in Cocoon too,
but he decided to make Cocoon2 SAX-only (u still can write DOM2SAX utility - but
this is less efficient, if u working directly with PDOM trees).
I was thinking a lot about this:
1. DOM API isn't good for Client/Server environment ... (even if it defined in
CORBA IDL - this is not efficient way).
Working directly with DOM is suitable only if database is embedded into your app
(like Ozone LocalDatabase).
Also DOM good for writing Server Extensions (in eXcelon terminology - equivalent
of Stored Procedures in RDBMS).
You can write Server Extensions using DOM API/XSLT/XPath.
2. SAX is good for C/S environment - u can stream events between remote machines
(u can't do this with DOM)
Example:
client sends XPath query to the Ozone Server (or invokes server extension / XSLT
processor),
the Ozone Server streams results of the query as SAX event to remote client ...
I evaluating eXcelon XML Data Server and I thing ODI going in right direction
(they also synched with latest W3C standars (XSLT\XPath), while Tamino using older
XQL (maybe b/c Jonathan Robie is working in Software AG :)
So ideal XML database server will have:
1. PDOM
2. XPath query engine (URL + Java interfaces)
3. server-side XSLT processor
4. Java server extensions (stored procedures) invokable from URL or remote Java
API
5. per Node triggers (node removed / inserted / updated)
6. SAX-based Client/Server API
7. XML Update language
8. Set of RDBMS to XML conversion utilities, like Oracle XML SQL / Cocoon's SQL
Processor utilities
As somebody told me: "Use XPath - like SQL WHERE clause and XSLT like SELECT,
ORDER-BY and SORT-BY"
Zvi