The current namespace of http://openaether.org/projects/jabber_database.html will be used until this becomes a jep. Once officially accepted as a jep and approved as final by the council, it will become http://www.xmpp.org/extensions/xep-0043.html.

• version - specify the version of the protocol that the client/server supports
• database - specify the database/catalog has the following attributes:
  • name - name of the database/catalog
  • sql - embed native SQL queries directly
  • table - the element scopes the children into the table. has the following attributes:
    • name - name of the table
    • permission - what the user can do with the data
    • col - describes the column. has the following attributes
      • name - name of the column
      • type - SQL99 datatype of the column
      • size - size of the datatype if required
      • op - comparison operator, used only if child of where element
    • where - scopes col elements into a 'sql-like' where clause
      • col - see above
  • proc - element scopes the children into a procedure has the following attributes:
    • name - name of the sproc
    • permission - what the user can do with the data
    • col - see above
    • result - indicated return value by running the procedure (restricted to integer)

There are a limited subset of data types available:

• bit - a single 'bit', usually used to represent boolean values
• tinyint - signed 8bit integer, has a range from -128 to +127
• integer - signed 32bit integer, has a range from -2147483648 to +2147483647
• utinyint - unsigned 8bit integer, has a range from 0 to +255
• uinteger - usigned 32bit integer, has a range from 0 to +4294967296
• float - allowed values are -3.402823466E+38 to -1.175494351E-38, 0, and 1.175494351E-38 to 3.402823466E+38 (can NOT be unsigned)
• numeric - unlimited size (some databases constrain this though)
• date - resolution is one day. acceptable ranges vary (TODO: constrain minimal range to something)
• datetime - a date and time combination (often has range dependencies)
• timestamp - a datetime used most often to record events
• time - a time in the format HH:MM:SS (TODO: specify valid range)
• char - an unsigned byte representing a single character (ASCII)
• vchar - a variable width char
• text - an extremely large chunk of text
• blob - an extremely large chunk of binary data (encode in MIME)

All SQL/RDBMS units will be scoped in the xml hierarchy:

All examples will assume the existence of the following rdbms setup. A database named 'testdb' with tables created with following SQL script:

This is a simple request to discover what tables/procedures exist on the database testdb. And what permissions are available to the user. All schema requests will respond within the scope that was asked for. This is to prevent unnecessary data from flooding the network. So the response for the above request would look something like:

The response is scoped to only the 'children' of the request. Since the request was for the testdb database, only the tables within that database were returned in the result. The reason for the limitation is to prevent excessively large packets from filling the network from large schemas.

The response indicates that the user has both read and write permissions on the table 'tbl_one' and only read permissions on the table 'tbl_two'. Consequently, the user may only perform get requests on 'tbl_two'.

The response would look like:

The schema response for tbl_one is quite intuitive. Three columns exist, one called a_int of type int (integer), another a_float of type float and a third called a_char of type char with a size of ten characters.

Manipulation of data (select, insert, update, delete) will definitely not be elegant or easy. SQL allows for some fairly complex queries on any fully functional RDBMS. Consequently, the data manipulation will be relatively limited since it is not a goal to translate SQL into xml.

Procedures, or stored procedures Apparently procedures are not as common in RDBMS as I thought. Postgres and MySQL have functions, but not procedures. So until I, or someone else, researches this issue this feature is on hold. , are often handy to make frequently used sql queries execute faster. These are simply queries stored in a precompiled form and given a name with a list of parameters. Each RDBMS handles procedures differently, but the common characteristics are that they are stored server side and have in/out parameters.

The <proc> element will be used to indicate a procedure. It has similar characteristics to the <table> element. The core differences are that the <col> elements have permissions and a <result> element can be used to indicate the value returned by the procedure.

The permission attribute on a <col> element is used to indicate whether the parameter is in (read), out (write) or in/out (both).

The only result set acceptable from a procedure is that of the parameters or <col> element. If the procedure produces a result set outside of the parameters this should be ignored.

The server must be able to let the client know when an error occurs, instead of just being silent.

If the user requests an action on a table which they do not have permission to do the following should be returned

If the user is not allowed to access the component the following should be returned

There are requirements which can be provided by other jabber components/namespaces, namely the jabber:iq:browse namespace in-place of Version Negotiation. Due to the inherent limitations of the above data retrieval mechanisms more sophisticated querying techniques might be desired. The <query> element will extend the functionality

Anyone care to do this?