[standards-jig] NEW JEP: Jabber Database Access
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