Re: OT: XML Server dream

[Eric van der Vlist <vdv@xxxxxxxxxxxx>]

Hi Stefano,

Stefano Mazzocchi wrote:
> 
> Eric van der Vlist wrote:
> >
> > Hi,
> >
> > I have been playing with XSL for a couple of months now.
> >
> > I store an increasing volume of information in XML files which are
> > formatted into HTML through XSL-T and can be edited either with a text
> > editor or using php scripts.
> >
> > The benefit is obvious and I will continue on this path.
> >
> > However, I am losing some of the benefits I had using a RDBMS
> > (PostgreSQL) and I wonder if it wouldn't be possible to combine XML/XSL
> > with a server approach.
> 
> 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.

I have been working during 6 for a RDBMS vendor and it may be why I tend
to like servers ;=) , but I'd like to be able to rely on a server to
handle this kind of issues.

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

> > By server, I mean a process which would store XML documents not

I shouldn't have say "process" here...

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

> > 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.
 
> > I have done some research on the web and I have found many documents
> > about "XML servers", but none of them seems to match with what I mean.
> >
> > Is my dream stupid or not feasible ?
> 
> Not stupid, a smart one. Feasible? sure, almost anything is, even
> starting an operating system from scratch and get much of the UNIX
> market :)

Or building a Java publishing framework in less than one year :) 

> The question is: do you really want to do it?

I don't know yet ;=) 
I'd like first to see the "state of the art"... and to share the effort
and the result of my researches.
 
> > If not, are you aware of any Open Source project going in this direction
> > ?
> 
> The new release of Cocoon (due early next week) has a new Processor that
> expands XML tags into their data meaning. An example for this will make
> things clearer. You write the following page (that of course, you keep
> well protected or use external entities to include your passwords)
> 
> <?xml version="1.0"?>
> <page>
>  <connectiondefs>
>   <connection name="foo_connection">
>    <driver>org.gjt.mm.mysql.Driver</driver>
>    <dburl>jdbc:mysql://mysql.example.com/foo_database</dburl>
>    <username>foo_user</username>
>    <password>foo_password</password>
>   </connection>
>  </connectiondefs>
> 
>  <query connection="foo_connection">
>   select name,number,message from foo_table order by name
>  </query>
> </page>
> 
> and the processors transforms it into something like
> 
> <?xml version="1.0"?>
> <page>
>  <result-set>
>   <tuple id="0">
>    <name>Donald Ball</name>
>    <number>23</number>
>    <message>The Illuminati do not exist. This message paid for by the
> Illuminati.</message>
>   </tuple>
>   ... other tuples ...
>  </result-set>
> </page>
> 
> the result tag set can be defined to match your exisings stylesheets or
> your DTD preferences. (The DTD used in the SQLProcessor is compatible
> with the Oracle XSQL Servlet which implements the exact same design
> pattern)
> 
> This is (IMO) a great way to "glue" RDBMS and XML web publishing.

I agree.

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

It looks like a big piece of what I have called XML Server.
 
> So, to sum up, I don't see the need for an XML server. I see the need
> for logic glue between existing database systems and XML publishing
> systems.
> 
> The Cocoon Project is already covering part of that ground and will
> follow that path in the future.

I was expecting an answer like this one and that's why I had also posted
my "dream" on the Cocoon list.

It's definitely a direction to evaluate.

I have played with Cocoon (1.3) for a while and the only point which has
disappointed me (but it may be the way I was using it) was performance.

I have never been able to get under 800 ms for the generation of simple
page on my test server.

This test server is only a small machine (Intel i586 150 MHz, 64 M RAM),
but with plain HTML Apache is incredibly fast.
 
> Needless to say, any contribution (either with code, ideas, bugfixes or
> anything) will be of great help and much appreciated. It would be sad to
> have more and more projects going to cover up the same ground.

I agree.
 
> Quoting something I read somewhere :) ...
> 
>     "E Pluribus Unum"
> 
> Take care.

Thanks for your feedback.

Eric


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