[standards-jig] NEW JEP: Jabber Database Access

Joe Hildebrand JHildebrand at jabber.com
Fri Aug 30 22:08:14 UTC 2002

I'm willing to be convinced about SQL vs. an XML-ized query language.
There's probably an 80%/20% effect, where 20% of the power of SQL suffices
for 80% of the things you need to do.  In practice, I've seen that people
keep wanting the next 1%, which makes the XML version more and more complex,
to the point where the XML is significantly more complex than the SQL.

One interesting, simplistic, approach in this space is the use of
"updategrams", which are (more-or-less) supported by MS SQL Server:


With respect to x:data, however, I'd urge you to go read the latest draft.
Ryan finally was able to get it through my thick skull that x:data isn't
just about forms, but also about transport of data.  Perhaps an example
would help.  Take your example 7 (response to basic select), and render it
like this in xml:

<iq id="003" type="result" from="db.host">
    <x xmlns="jabber:x:data" type="result"
        <field var="a_int"   xsi:type="xsd:integer"/>
        <field var="a_float" xsi:type="xsd:float"/>
        <field var="a_char"  xsi:type="xsd:string"/>
        <field var="a_int"><value>1234</value></field>
        <field var="a_float"><value>123.45</value></field>
        <field var="a_char"><value>onetwothre</value></field>
        <field var="a_int">2345<value></value></field>
        <field var="a_float">234.56<value></value></field>
        <field var="a_char"><value>twothreefo</value></field>

So, the <database/> tag still exists, mostly to provide context.  The <x>
section contains the data in a generic way.  The <reported/> section has the
metadata about the results, including xsi:type definitions.  Each row of
results has an <item/> tag, containing one field per column.

Joe Hildebrand

> -----Original Message-----
> From: Justin Kirby [mailto:justin at openaether.org]
> Sent: Wednesday, August 28, 2002 1:09 PM
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] NEW JEP: Jabber Database Access
> 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 
> limitation.
> 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 
> stream.
> Justin
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list