Re: OT: XML Server dream

["Steve Muench" <smuench@xxxxxxxxxxxxx>]

| > Many people are concerned about how to combine legacy stuff with the new
| > XML/XSL model. This is a key issue for XML wep publishing and clearly
| > understood.
|
| Nice to know I am not the only one :=) !
| It's not only what I meant : for me it's not only a matter of combining
| legacy stuff (personally I have started my company less than 1 year ago
| and I don't have that much legacy :=))
| I am afraid of increasing the amount of XML data since I do not know how
| I'll manage all these files and I don't know either how I'll manage
| files which DOMs do not fit in memory.

With all due respect, maybe the problem is that you are
thinking of the problem as a *file*-management problem
instead of thinking of it as an *information*-management
problem -- the information those files contain. The *file*
is a convenient format to retrieve and exchange the information,
for sure. If the file is semistructed, like a marked-up
Shakespeare play, then storing the doc in meaningful chunks
or entirely as a document is usually the best route. If the
document is just some tags around a rich data structure, then
storing it relationally or object/relationally will work just
fine (and leave you the flexibility of presenting that information
in *many* different file structures/formats.

| It may not be a complete physical server but some glue between other
| projects and products, but I'd like to have "something" on which to rely
| to manage my XML information as I used to rely on a RDBMS to manage by
| SQL information...

Your dream-server to me sounds like a relational database with
easy XML-in and XML-out capabilities and the ability to layer
arbitrary, richly-structurely XML "Views" over your
easy-to-query, easy-to-manage, easy-to-maintain enterprise
relational database. With something like this you can
serve the *information* of interesting links as:

 -> A netscape RSS file
 -> A moreover.com new file
 -> An RDF document
 -> An active HTML website people visit directly
 -> An XBEL Bookmark Interchange file

Using a powerful combination of SQL, XML, and XSLT.

I think Stefano Mazzocchi, Donald Ball, Stefano Malimpensa,
and myself all see very similarly on the awesome power
of flexible use of XML from and into the a relational database
combined with the ability to transform the information into
the format that serves at the moment. Likely many others do too,
but just aren't as vocal as these guys ;-> on the lists.

| > > necessarily in their text format, cache a domlike structure and manage
| > > all the concurrency issues (yes, I mean transactional XML...).
| >
| > I think you're saying too many things at once.
| >
| > 1) persistent storing methodology
| > 2) concurrency issues.
| >
| > I don't have to rethink the "ACID" properties of transactions: all good
| > DBMS implement them. No need to reinvent the wheel.
|
| No, but we need ACID properties on part of XML trees if we want to
| update them in a transactional way.

In many cases the "part" you want to update is simply updating a column
in a table which stores that "part". With utilities like the OracleXMLQuery
and OracleXMLSave (up on our OTN site at http://technet.oracle.com/tech/xml)
you can have that XML-in and XML-out today. When combined with
transformation
in both directions, the possibilities are quite rich.

| > What you need is a powerful way to combine your existing DBMS with your
| > XML publishing framework and yes, a smarter way would be to store a
| > "serialized" version of your classes to "compile" XML parsing in the
| > serialized memory structure (and all you need is a serializable DOM
| > implementation a little JDBC glue logic and a well known database
| > schema)
|
| If it be done by adding some glue, let's do it !

The glue is already available for your prototyping. See the URL above.
As Stefano M. mentioned, current versions of Cocoon and the Oracle XSQL
Page Processor/Servlet will let you try out what you're thinking I
believe.

| > > This server should be capable to process queries written in XSL-T, but
| > > also to process update statements (maybe as XSL extensions) and
| > > administration commands.
| >
| > ? what for? Do you want to manage your database with XSLT commands?
| > weird idea... databases already have their tools for management.
|
| Is it so weird ?
| How do you manage complex or huge XML documents ?
| How, for instance, do you update a node in such a document like an ODP
| (http://dmoz.org) RDF dump ?

Your word "dump" is exactly what I'm referring to. This is a "dump" in
RDF of a bunch of information that could be in one or more tables in
your favorite relational db.

| > > It would be for XML data and XSL processing, what RDBMS are for
| > > relational data and SQL.
| >
| > I think you might end up loosing focus: you should try to use what's
| > available and find useful ways to combine them. It's easier to code,
| > faster to get out, easier to users to use (since this doesn't impact
| > their systems).
|
| My goal is on the contrary to define a features list and to search which
| products can be used to meet this list.

It would be useful to start with Cocoon and Oracle XSQL Servlet and
then voice your requirements as a list of "can't live withouts"
based on the current functionality you see there.

| (The DTD used in the SQLProcessor is compatible
| > with the Oracle XSQL Servlet which implements the exact same design
| > pattern)

Cool. I've been trying with XSQL Servlet to stick to the bare minimums
necessary to really let the raw power of the combination of XML, SQL
and XSLT shine through. It's exciting to see this idea taking off
in other places like Cocoon, too.

| > Another component that is being created will be able to store XML in a
| > parsed-serialized state in DMBS as BLOB or text (depending on databases
| > used). This won't be available in Cocoon 1.5 as it's being worked on but
| > will probably in Cocoon 1.6. It will probably coupled by a file-upload
| > tool that will perform XML validation and database insertion. Any help
| > on this will be very appreciated.

Again, check out the OracleXMLSave utility which can
help you jumpstart these kinds of XML-into-the-DB
activities.

Just like the OracleXMLQuery and XSQL Servlet, the OracleXMLSave,
this works with any JDBC driver and any database.
________________________________________________________
Steve Muench, BC4J Development Team & XML Evangelist
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list