[standards-jig] NEW JEP: Jabber Database Access

Justin Kirby justin at openaether.org
Wed Aug 28 19:09:01 UTC 2002

Joe Hildebrand wrote:

>Is there any reason why we need a new SQL syntax?  What I mean is, is this
>JEP still useful if it only specifies the embedded query approach?  Once you
>fully xml-ize SQL, you will have recreated all of the complexity and
>incompatibility of SQL.  I've been down this road several times, and have
>*never* been pleased with the results.
The jep is not intended to fully recreate sql in xml as noted in the 
introduction.  The <sql/> element is used as a workaround to this 

As you mentioned, sql is extremely complex and non-portable, recreating 
it in xml would be both pointless and error prone. Boiling the jep down 
to <sql/> would force both clients and components to fully understand 
sql and all the portability issues, thus having to know what rdbms was 
sitting behind the component. This also brings in security issues if the 
component fails to parse the sql syntax correctly. Which is why <sql/> 
is an optional feature.

>I can understand the need for meta-data, for table descriptions.  Could we
>extend the x:data <reported/> section, to have column sizes and null
>constraints, and get all of this functionality?  I'm not sure about this
>one.  It just seems like there's a possibility.
>Is there any way to leverage x:data in the select result sets?  I think that
>the <item/> syntax, along with the <reported/> description approach from the
>latest draft is a nice fit.
My understanding is that x:data is intended to provide a means of 
displaying a structured form without placing UI dependencies on the 
client. I could not see x:data being used for component to component 
communication. And I see no reason to extend x:data beyond its original 
intentions, it does what it does well.

The jep does not aim to provide direct user interaction (though it could 
be).  The goal is to get data from an rdbms (or any other structured 
data source) onto the jabber network while placing as few requirements 
on the implementation as possible.

Sql was used as a base. I am not completely satisfied with the where 
clause and would love suggestions for a replacement. I admit that 
<where/> does not fit well into xml at all. However, since I lacked a 
better method I was forced to go with that.

I briefly entertained the idea of using xpath or xselect. The problem is 
that the jabber protocol itself doesn't mesh well with these, since they 
are intended to work on an entire document and not partial packets in a 


More information about the Standards mailing list