/
xep-0043.xml
797 lines (714 loc) · 28.5 KB
/
xep-0043.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Database Access</title>
<abstract>Expose RDBM systems directly to the jabber network</abstract>
&LEGALNOTICE;
<number>0043</number>
<status>Retracted</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author>
<firstname>Justin</firstname>
<surname>Kirby</surname>
<email>justin@openaether.org</email>
<jid>zion@openaether.org</jid>
</author>
<revision>
<version>0.2</version>
<date>2003-10-20</date>
<initials>psa</initials>
<remark>At the request of the author, changed status to Retracted.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-08-21</date>
<initials>jk</initials>
<remark>Initial public release</remark>
</revision>
</header>
<section1 topic='Introduction'>
<p>Accessing a RDBMS in a generic fashion is a complex and difficult
task. Consequently, this will not be an attempt to XMLize a generic
Database API or query language. Instead, it will providing a
simple mechanism for a JID to read/write data that it has access to
and specifying a model for those schemas to use in xml.</p>
<p>This document has two aims.</p>
<ol>
<li>Be able to request the available schemas</li>
<li>Perform near SQL-like data manipulation</li>
</ol>
<p>Although designed for use with an RDBMS this document is not
restricted to such uses. It may be used with any data storage
system that can be broken down to a simple table, column/row
format. for example comma delimited files.</p>
</section1>
<section1 topic='Prerequisites'>
<p>To understand the following sections of this document the reader
must be aware of the following.</p>
<section2 topic='Namespace'>
<p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
will be used until this becomes a jep. Once officially accepted as
a jep and approved as final by the council, it will become
<link>http://www.xmpp.org/extensions/xep-0043.html</link>.</p>
</section2>
<section2 topic='Elements'>
<ul>
<li>version - specify the version of the protocol that the client/server supports</li>
<li>database - specify the database/catalog has the following attributes:
<ul>
<li>name - name of the database/catalog</li>
<li>sql - embed native SQL queries directly</li>
<li>table - the element scopes the children into the table. has the following attributes:
<ul>
<li>name - name of the table</li>
<li>permission - what the user can do with the data</li>
<li>col - describes the column. has the following attributes
<ul>
<li>name - name of the column</li>
<li>type - SQL99 datatype of the column</li>
<li>size - size of the datatype if required</li>
<li>op - comparison operator, used only if child of where element</li>
</ul>
</li>
<li>where - scopes col elements into a 'sql-like' where clause
<ul>
<li>col - see above</li>
</ul>
</li>
</ul>
</li>
<li>proc - element scopes the children into a procedure has the following attributes:
<ul>
<li>name - name of the sproc</li>
<li>permission - what the user can do with the data</li>
<li>col - see above</li>
<li>result - indicated return value by running the procedure (restricted to integer)</li>
</ul>
</li>
</ul>
</li>
</ul>
</section2>
<section2 topic='Data Types'>
<p>There are a limited subset of data types available:</p>
<ul>
<li>bit - a single 'bit', usually used to represent boolean values</li>
<li>tinyint - signed 8bit integer, has a range from -128 to +127</li>
<li>integer - signed 32bit integer, has a range from -2147483648 to +2147483647</li>
<li>utinyint - unsigned 8bit integer, has a range from 0 to +255</li>
<li>uinteger - usigned 32bit integer, has a range from 0 to +4294967296</li>
<li>float - allowed values are -3.402823466E+38 to
-1.175494351E-38, 0, and 1.175494351E-38 to 3.402823466E+38 (can NOT be unsigned)</li>
<li>numeric - unlimited size (some databases constrain this though)</li>
<li>date - resolution is one day. acceptable ranges vary (TODO: constrain minimal range to something)</li>
<li>datetime - a date and time combination (often has range dependencies)</li>
<li>timestamp - a datetime used most often to record events</li>
<li>time - a time in the format HH:MM:SS (TODO: specify valid range)</li>
<li>char - an unsigned byte representing a single character (ASCII)</li>
<li>vchar - a variable width char</li>
<li>text - an extremely large chunk of text</li>
<li>blob - an extremely large chunk of binary data (encode in MIME)</li>
</ul>
</section2>
<section2 topic='Assumed Database Setup'>
<p>All SQL/RDBMS units will be scoped in the xml hierarchy:</p>
<code>
<database>
<table>
<col/>
</table>
</database>
</code>
<p>All examples will assume the existence of the following rdbms setup. A
database named 'testdb' with tables created with following SQL
script:</p>
<code>
create table tbl_one
(
a_int int,
a_float float,
a_char char(10)
)
create table tbl_two
(
a_date datetime,
a_numeric numeric(9,3)
)
</code>
</section2>
</section1>
<section1 topic='Usage'>
<section2 topic='Requesting Schemas'>
<example caption='A simple schema request'>
<iq id="001" to="db.host" type="get">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
</iq>
</example>
<p>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:</p>
<example caption='Response to a schema request'>
<iq id="001" type="result" from="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one" permission="both"/>
<table name="tbl_two" permission="read"/>
</database>
</iq>
</example>
<p>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.</p>
<p>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'.</p>
<example caption='Request detailed table schema'>
<iq id="002" type="get" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one"/>
</database>
</iq>
</example>
<p>The response would look like:</p>
<example caption='Response to detailed request'>
<iq id="002" type="result" from="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one" permission="both">
<col name="a_int" type="int"/>
<col name="a_float" type="float"/>
<col name="a_char" type="char" size="10"/>
</table>
</database>
</iq>
</example>
<p>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.</p>
</section2>
<section2 topic='Manipulating Data'>
<p>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.</p>
<section3 topic='Selects'>
<p>To indicate a select like query, specify an <iq> of
type get. The table that the query is to be performed against
must be specified. The columns that are to be returned in
the result set must be scoped within the relative table.
Any attribute on the <col> element besides name will be
ignored. e.g. it is not required nor recommended to specify
the data types or the sizes while performing a get.</p>
<example caption='Basic select'>
<iq id="003" type="get" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<col name="a_int"/>
<col name="a_float"/>
<col name="a_char"/>
</table>
</database>
</iq>
SQL Syntax:
select a_int, a_float, a_char
from tbl_one
</example>
<p>It is also possible to specify a limit on the number of rows
returned in the result set by specifying a value for the limit
attribute.</p>
<example caption='Basic select with limit'>
<iq id="003" type="get" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one" limit="2">
<col name="a_int"/>
<col name="a_float"/>
<col name="a_char"/>
</table>
</database>
</iq>
</example>
<p>In this case a limit of two rows will be returned in the result set.</p>
<p> The result set which is returned will contain all the rows
that met the criteria of the select. There is no schema
information beyond the column names included in the result set.
Each 'row' in the result set is scoped within the corresponding
<table> element. This allows for queries on multiple
tables to be used in one <iq> packet.</p>
<example caption='Response to basic select'>
<iq id="003" type="result" from="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<col name="a_int">1234</col>
<col name="a_float">123.45</col>
<col name="a_char">onetwothre</col>
</table>
<table name="tbl_one">
<col name="a_int">2345</col>
<col name="a_float">234.56</col>
<col name="a_char">twothreefo</col>
</table>
</database>
</iq>
</example>
</section3>
<section3 topic='Constraining Result Sets'>
<p>It would be impractical to request the entire contents of the
table every time you needed one row or a subset of the data. You
can constrain the result set by specifying a where clause.</p>
<example caption='Select with constraints'>
<iq id="004" type="get" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<col name="a_int"/>
<col name="a_float"/>
<col name="a_char"/>
<where>
<col name="a_int" op="eq">1234</col>
<col name="a_float" op="lt" conj="and">200.00</col>
</where>
</table>
</database>
</iq>
SQL Syntax:
select a_int, a_float, a_char from tbl_one
where a_int = 1234 and a_float < 200.00
</example>
<p>Attributes only used in the <col> element within a
<where> element are the op (for operator) and conj for
(conjunction). The op is used for comparison operators such
as <, >, =, <>, <=, >=</p>
<ul>
<li>eq - equivalent =</li>
<li>neq - not-equivalent <></li>
<li>lt - less than <</li>
<li>gt - greater than ></li>
<li>let - less than or equivalent <=</li>
<li>get - greater than or equivalent >=</li>
<li>null - IS NULL (the column is null in the database sense of the word)</li>
</ul>
<p>The conjuction attribute is used to combined constraints in the where clause</p>
<ul>
<li>not - to negate a result</li>
<li>or - logical OR ||</li>
<li>and - logical AND &&</li>
</ul>
<p><strong>Result</strong></p>
<example caption='Response to select with constraints'>
<iq id="003" type="result" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<col name="a_int">1234</col>
<col name="a_float">123.45</col>
<col name="a_char">onetwothre</col>
</table>
</database>
</iq>
</example>
</section3>
<section3 topic='Inserts'>
<p>Inserting or altering the stored data in anyway requires
setting the type attribute to a value of set. This indicates
that the user wants to perform a 'insert/update'. The
differentiating factor between an insert and an update operation
is whether a <where> element is used. If there is no
<where> element then it must be interpreted as an insert.
If a <where> element does exist, then it must be
interpreted as an update.</p>
<example caption='Inserting data'>
<iq id="004" type="set" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<col name="a_int">3456</col>
<col name="a_float">345.67</col>
<col name="a_char">threefour</col>
</table>
<table name="tbl_two">
<col name="a_date">02/16/2002</col>
<col name="a_numeric">123456789123.123</col>
</table>
</database>
</iq>
SQL syntax:
insert tbl_one (a_int, a_float,a_char)VALUES(3456, 345.67, 'threefour')
insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</example>
<p><strong>Result</strong></p>
<p> If there is no result set for the query, as in an update,
insert, delete, then the response must indicate success or
failure within the <table> element scope. An empty
<table> element indicates success, and a <table>
element containing an <error> element indicates a failure.</p>
<example caption='Response to data insert'>
<iq id="004" type="result" from="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one"/>
<table name="tbl_two">
<error code="380">permission denied on table</error>
</table>
</database>
</iq>
</example>
<p> The insert into tbl_one succeeded since the response has an
empty <table> element. However, the insert into tbl_two
failed with a permission denied error. Which is indicated with a
non-empty <table> element.</p>
</section3>
<section3 topic='Updates'>
<p> As stated previously, if the type attribute has a value of
set and a <where> element exists, then it must be interpreted as an update.</p>
<example caption='Updating'>
<iq id="005" type="set" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<col name="a_char">aaaaaaaaaa</col>
<where>
<col name=c"a_int">1234</col>
</where>
</table>
</database>
</iq>
SQL Syntax:
update tbl_one
set a_char = 'aaaaaaaaaa'
where a_int = 1234
</example>
<p><strong>Result</strong></p>
<p> Again, if there is no result set returned by the query, then
success or failure must be indicated.</p>
<example caption='Response to update'>
<iq id="005" type="result" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one"/>
</database>
</iq>
</example>
</section3>
<section3 topic='Deletes'>
<p> If the type attribute has a value of set and there are no
<col> elements scoped within the <table> element,
then the query must be interpreted as a delete.</p>
<example caption='Simple delete'>
<iq id="006" type="set" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one">
<where>
<col name="a_int" op="eq">1234</col>
</where>
</table>
</database>
</iq>
SQL Syntax:
delete from tbl_one where a_int = 1234
</example>
<p><strong>Result</strong></p>
<p>Again, if a result set is not generated by a query, then
success or failure must be indicated by the <table> element</p>
<example caption='Response to delete'>
<iq id="006" type="result" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one"/>
</database>
</iq>
</example>
</section3>
</section2>
<section2 topic='Procedures'>
<p> Procedures, or stored procedures <note>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.</note>
, 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.</p>
<p> 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.</p>
<p> The permission attribute on a <col> element is used to
indicate whether the parameter is in (read), out (write) or in/out (both). </p>
<p> 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.</p>
</section2>
<section2 topic='Errors'>
<p> The server must be able to let the client know when an error
occurs, instead of just being silent.</p>
<table caption='Error Codes'>
<tr>
<th>Code</th>
<th>Message</th>
<th>Description</th>
</tr>
<tr>
<td>399</td>
<td>Invalid Database Name</td>
<td>Returned when the client has requested information from a
database which does not exist according to the component.</td>
</tr>
<tr>
<td>398</td>
<td>Invalid Table Name</td>
<td>Returned when the client has requested information from a
table/procedure which does not exist according to the component.</td>
</tr>
<tr>
<td>397</td>
<td>Invalid Column Name</td>
<td>Returned when the client has requested information from a
column which does not exist according to the component.</td>
</tr>
<tr>
<td>380</td>
<td>Permission Denied on Table</td>
<td>Returned when the requested action is not allowed for the
user on the table</td>
</tr>
<tr>
<td>401</td>
<td>Access Denied</td>
<td>Returned when the user does not have permission to use the
component.</td>
</tr>
</table>
<p>If the user requests an action on a table which they do not have
permission to do the following should be returned</p>
<example caption='Permission denied error'>
<iq id="004" type="error" from="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_two">
<error code="380">permission denied on table</error>
</table>
</database>
</iq>
</example>
<p>If the user is not allowed to access the component the following should be returned</p>
<example caption='General access denied'>
<iq id="004" type="error" from="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<error code="401">Access Denied</error>
</database>
</iq>
</example>
</section2>
<section2 topic='Optional Features'>
<p> 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 </p>
<section3 topic='Embedded SQL'>
<p> The abilities described in the Basics section are just that,
basic. To provide more flexibility and allow for the full power
of SQL without xmlifying everything, a <sql> element may
be implemented to provide this feature.</p>
<p> The <sql> element must be scoped within the <database> element.</p>
<example caption='Embedded sql query'>
<iq id="007" type="get" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<sql> select a_int, a_float from tbl_one </sql>
</database>
</iq>
</example>
<p><strong>Result</strong></p>
<example caption='Response to embedded query'>
<iq id="007" type="result" to="db.host">
<database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/>
<table name="tbl_one" permission="both">
<col name="a_int" type="integer"/>
<col name="a_float" type="float"/>
</table>
<table name="tbl_one">
<col name="a_int">1234</col>
<col name="a_float">123.45</col>
</table>
<table name="tbl_one">
<col name="a_int">2345</col>
<col name="a_float">234.56</col>
</table>
</database>
</iq>
</example>
<p> Since SQL is so flexible, the result set schema is not known
until it is returned as a result of the query. Consequently, it
must be sent as the first 'row' of the returned result. Each
following row will be the actual data queried for.</p>
<p> If multiple tables are used within one SQL statement, then
then name attribute within the <table> element can not be
accurately denoted with a single table name. The best way to deal
with this situation is to simply use a unique identifier within
the scope of the <database> element. This will allow for
multiple <sql> results to be scoped within the same result.</p>
</section3>
<section3 topic='Version Negotiation'>
<p>It is expected that this protocol will grow and be extended
to meet various demands. Therefore, version
negotiation<note>Version Negotiation is being killed since browsing, feature
negotiation, or disco will be able to perform this function,
however it might be useful as an optional feature for clients
that don't implement these yet, especially considering none
of these have been standardized.</note> will be
incorporated up front.</p>
<p>When the connection initiator, client end-user or
server/transport, starts a session, it must first send
the version number it expects to use, otherwise, behavior
is undefined.</p>
<code>
<iq id="000" type="get" to="db.host">
<database
xmlns="http://openaether.org/projects/jabber_database.html">
<version>0.1</version>
</database>
</iq>
</code>
<p>Three responses are possible from the server.</p>
<ol>
<li>
<p>It supports that version number and responds with:</p>
<code>
<iq id="000" type="result" from="db.host">
<database
xmlns="http://openaether.org/projects/jabber_database.html">
<version>0.1</version>
</database>
</iq>
</code>
<p>The type of 'result' indicates that the version request was
successful and if the client is satisfied with the version number,
may continue with schema requests or whatever.</p></li>
<li><p>It does not support that version number and responds with:</p>
<code>
<iq id="000" type="error" from="db.host">
<database
xmlns="http://openaether.org/projects/jabber_database.html"/>
</iq>
</code>
<p>The type of 'error' indicates a failure in conforming to the
desired version number. The server may optionally send an
alternative option.</p>
<code>
<iq id="000" type="error" from="db.host">
<database
xmlns="http://openaether.org/projects/jabber_database.html">
<version>0.2</version>
</database>
</iq>
</code></li>
<li>If the server has no idea what the client is talking
about it should send the appropriate Jabber error code.</li>
</ol>
</section3>
</section2>
</section1>
<section1 topic='Limitations'>
<ol>
<li>No joins, roll ups, cubes</li>
<li>Views are not differentiated from tables</li>
<li>provides basic sql-like functionality only</li>
<li>Utilizes <em>lowest common denominator</em> approach</li>
</ol>
</section1>
<section1 topic='Todos'>
<ul>
<li>define procedures; what they are and how they work</li>
<li>determine value of adding administration features</li>
</ul>
</section1>
<section1 topic='Thanks'>
<p>Thanks to Russell Davis (ukscone) for fine tuning the layout and wording of this jep. It would probably have been unreadable if it wasn't for him.</p>
</section1>
<section1 topic='DTD and Schema'>
<section2 topic='DTD'>
<code>
<!ELEMENT version (#PCDATA)>
<!ELEMENT error (#PCDATA)>
<!ELEMENT sql(#PCDATA)>
<!ELEMENT database (table | sproc | sql | error)*>
<!ELEMENT table (col | where | error)*>
<!ELEMENT where (col+)>
<!ELEMENT col (#PCDATA)>
<!ELEMENT proc(col | result | error)*>
<!ELEMENT result (#PCDATA)>
<!ATTLIST error code CDATA #IMPLIED>
<!ATTLIST database name CDATA #IMPLIED>
<!ATTLIST table
name CDATA #IMPLIED
permission (read | write | both) #IMPLIED
limit CDATA #IMPLIED
>
<!ATTLIST proc name CDATA #IMPLIED>
<!ATTLIST col
name CDATA #IMPLIED
size CDATA #IMPLIED
op (eq | neq | lt | gt | let | get | null) #IMPLIED
conj (not | or | and ) #IMPLIED
permission (read | write | both) #IMPLIED
type (bit | tinyint | integer | utinyint | uinteger |
float | numeric | date | datetime | timestamp |
time | char | vchar | text | blob) #IMPLIED
>
</code>
</section2>
<section2 topic='Schema'>
<p><strong>Anyone care to do this?</strong></p>
</section2>
</section1>
</xep>