Re: OT: XML Server dream

[Eric van der Vlist <vdv@xxxxxxxxxxxx>]

Hi Steve,

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

You're right, this is the key point and I am afraid I have not have been
very clear !

I am a RDBMS fan and I'd like, on the contrary, to be able to rely on a
single server or repository for all the information posted on a web site
: the information which easily fits in  RDBMS tables, but also the
content of traditional pages.

It's because I'd like to avoid file management issues and because I'd
prefer to think in terms of information than in terms of files that I
have begun this thread.

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

If you accept to split information between tabular and rich text
information, the architecture you're describing below is fine.

If you want to go further and if your long term goal is to handle the
information on a web site as a whole, you probably reach the limits of
the relational model.

I am not saying that we should just throw RDBMS away, but if the users
or administrators, but having a single interface for managing both kind
of information would be so much simpler !

>From a user prospective, there is only one kind of information : a phone
number is a phone number, the fact that it comes in a list or within a
text doesn't make any difference. Couldn't we give the same coherent
vision to DBA's or web designers ?

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

I can give a concrete example of what I'm currently implementing on one
of our web sites.

We are selling to the shop owners of our district pages on a proximity
site (see for instance http://dupleix.ducotede.com/dubois/).

In these pages, we are mixing information from a RDBMS (name, phone
number, address, ...), free text and pictures.

We want, of course the free text and the presentation to be very
flexible.

We have therefore stored the free text and layout in XML files and the
other data in the RDBMS.

It's working fine, but it's not easy to manage, especially when you want
to develop web based tools to let the users update both the data
available in the RDBMS and in the XML files and have to cope with
updating two very different kinds of media.
 
> | > 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.

I haven't said that this option was not to be considered !
 
> | > > 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.

Yes, except that managing hierarchical structures like those described
by these RDF dumps may not be the greatest strength of my 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.

Well taken !
I won't forget to have them in our products list.

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

Thanks for your helpful post.

Eric

-- 
------------------------------------------------------------------------
Eric van der Vlist                                              Dyomedea

http://www.dyomedea.com                          http://www.ducotede.com
------------------------------------------------------------------------


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