cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Inheritance in XML for SQLProcessor
Date Tue, 14 Dec 1999 13:32:34 GMT
Donald Ball wrote:
> Hey guys. I was working on adding some new features to SQLProcessor when I
> just got a little fed up with the way I'm doing 'default' attributes for
> query tags. Currently, when I'm working with a query element, I must
> possibly look to two referenced nodes, connection and querydefs to
> determine connection and query attributes. E.g.:
> <connectiondefs>
>  <connection name="foo">
>   ...
>  </connection>
>  <querydefs name="bar" attribute="value"/>
> </connectiondefs>
> <query connection="foo" defs="bar">
>  ...
> </query>
> in this instance, the query node references a 'foo' connection node for
> some connection parameters and a 'bar' querydefs node for some query
> attributes. The syntax, however, isn't formalized, and it seems like
> things would be clearer and easier both in the java code and the XML
> documents if I had a standard syntax for allowing XML nodes to inherit
> attributes from other XML nodes. 

I have the same problem in Cocoon2 (did you guys look at the new Cocoon2
branch in the CVS?) and also in Avalon and, we'll have it on every other
XML data binding realm.

OO design mixed with XML.

Suppose you have something like this

<config xml:extends="res://org/apache/cocoon/cocoon.xml">
 <processor type="sql"
 <cache class="org.apache.cocoon.cache.NoCache"/>

this XML config file is created "extending" the given xml template file
(which would be packaged inside Cocoon) and inheriting all the rest of
the elements so, for example:




<a xml:extends="defaults.xml">

would generate


The algorithm to generate the "merging" should not be hard to develop.
(Tim: is there anything like this planned in the future of XML?

> I coded up a quick solution that lets me
> do something like this:
> <sqldefs
>  ID="23"
>  driver=""
>  doc-element="options"
>  row-element="option"
> />
> <query extends="sqldefs.23">
>  select * from foo_Table
> </query>
> The algorithm is quite simple. If the processor doesn't find an attribute
> on the query node that it's looking for, it looks for the referenced by
> the extends attribute and, if it exists, repeats the procedure on the
> referenced node. Ideally, I'd like to allow an XPath expression in the
> extends attribute, but since we don't have a library function to do that
> yet, I'm using my own silly syntax - node_name.ID_attribute_value.

Hmmm, reminds me of the "fill the blanks with XSLT" exercise to the
reader. Wouldn't it be better to have some other machinery do this for
all XML files? Then you have your own filled up XML file you can work on
out of the box, but its syntax is rather flexible.
> I never liked the blahdefs node names anyway, it was just a quick'n'dirty
> reimplementation and extension of Oracle's XSQL servlet syntax. Moving to
> this syntax will mean that existing users will be forced to alter their
> XML files, unfortunately. Is there anyone who's terribly averse to this
> change? If so, please speak up since I'd like to implement this before we
> get to the stage that changes in the DTD require lots of changes. 

I know it's hard, but a DTD should not change that easily. I know this
is bleeding edge technology, but we should try to come up with a decent
proposal for a unified XSQL DTD.

Steve, would you like to work with us on that? Maybe a W3C proposal
could come out, what do you think?

> There are three basic implications to consider:
> 1. Existing connection and querydefs nodes must be converted and possibly
> merged. I don't think anyone's using SQLProcessor for anything useful in
> production yet except for me, so this probably isn't a huge deal.

If you start with this idea, people will follow you and stay away from
> 2. It's possible to inherit attributes from grandparents with this syntax.
> I think that's desirable, but others may disagree.

No, XML inheritance and other OO abilities are great features and XML is
currently missing them. (there is a XML data binding proposal going on
in Sun, but that doesn't affect this, only XML to Javabean mapping)
> 3. We'll have broken almost completely from Oracle's XSQL servlet syntax.
> I don't necessarily like this but a) we've already have many more features
> and b) I don't want to be tied to their syntax.

I think both you and Steve have the same goals: relational to XML
binding thru JDBC. I really don't see why we need to differ, but this
might well be influenced by global Oracle's attitude toward open source.
Steve, let's hear your comments.
> 4. I'm not aware of any standards that have been proposed for XML
> attribute inheritance. If there are any, it would be ideal if SQLProcessor
> could just support one of them.

You should not inherit only attributes, but also elements, PIs and
comments. Validation ability would be greatly effected by this... hmmm,
maybe at XSchema are thinking about XML inheritance.

> Anyway, speak up if you care, otherwise I'm going to move ahead with this.
> FYI, the reason I'm so gung-ho about changing this right now is because it
> should make it easier to add transaction and subquery support, like so:
> <transaction>
>  <query .../>
>  <query .../>
> </transaction>
> <query ID="parent" ...>
>  select id,department_name from department_table
>  <query extends="query.parent">
>   select first_name,last_name from employee_table where department_id = {$id}
>  </query>
> </query>
> (where {$id} corresponds to the id column value from the resultset of the
> outer query)
> and I'm rather in need of the latter feature for a project I'm working on
> right now. :)

I don't have problems with you doing that, as long as you come up with
documents that expose the changes.

Donald, must I remind you that your not-yet-xmlized documents are the
release stopper for Cocoon 1.6? :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message