Subject: Re: OT: XML Server dream From: Stefano Mazzocchi <stefano@xxxxxxxxxx> Date: Sun, 24 Oct 1999 02:02:22 +0200 |
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. > By server, I mean a process which would store XML documents not > 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. 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) > 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. > 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). > 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 :) The question is: do you really want to do it? > 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. 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. 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. 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. Quoting something I read somewhere :) ... "E Pluribus Unum" Take care. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <stefano@xxxxxxxxxx> Friedrich Nietzsche --------------------------------------------------------------------- XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: OT: XML Server dream, uche . ogbuji | Thread | Re: OT: XML Server dream, Eric van der Vlist |
limitations of xslt, Earl Bingham | Date | Re: OT: XML Server dream, Eric van der Vlist |
Month |