index.html
78.5 KB
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
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en-US"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>XML Protocol Abstract Model</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
dt.label { display: run-in; }
li p { margin-top: 0.3em;
margin-bottom: 0.3em; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
DT {
MARGIN-TOP: 0.5em; MARGIN-BOTTOM: 0.5em
}
hanging indent { text-indent: -1in; margin-left: 1in }
DD.charter {
FONT-STYLE: italic
}
LI.charter {
FONT-STYLE: italic
}
LI.change {
FONT-SIZE: smaller
}
SPAN.charter {
FONT-STYLE: italic
}
P.charter {
FONT-STYLE: italic
}
P.caption {
FONT-WEIGHT: bold
}
P.code {
MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt
}
P.ednote {
BACKGROUND-POSITION: 0% 50%; BACKGROUND-ATTACHMENT: scroll; BACKGROUND-REPEAT: repeat; FONT-STYLE: italic; BACKGROUND-COLOR: yellow
}
P.prev {
FONT-SIZE: smaller
}
P.change {
FONT-SIZE: smaller
}
SPAN.ednote {
BACKGROUND-POSITION: 0% 50%; BACKGROUND-ATTACHMENT: scroll; BACKGROUND-REPEAT: repeat; FONT-STYLE: italic; BACKGROUND-COLOR: yellow
}
P.illustration {
TEXT-ALIGN: center
}
caption {
FONT-WEIGHT: bold
}
.strike {
text-decoration: line-through;
color: silver;
}
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"></head><body>
<div class="head">
<p>
<a href="http://www.w3.org/" title="Go to W3C Home Page">
<img width="72" height="48" alt="W3C"
src="http://www.w3.org/Icons/w3c_home">
</a>
</p>
<h1>XML Protocol Abstract Model</h1>
<h2>W3C Working Draft 20 February 2003</h2>
<dl>
<dt>This version:</dt>
<dd><a href="http://www.w3.org/TR/2003/WD-xmlp-am-20030220/">http://www.w3.org/TR/2003/WD-xmlp-am-20030220/</a></dd>
<dt>Latest version:
<dd><a href="http://www.w3.org/TR/xmlp-am/">http://www.w3.org/TR/xmlp-am/</a></dd>
<dt>Previous version:</dt>
<dd><a href="http://www.w3.org/TR/2001/WD-xmlp-am-20010709/">http://www.w3.org/TR/2001/WD-xmlp-am-20010709/</a></dd>
<dt>Editors:</dt>
<dd>Stuart Williams, Hewlett-Packard Company <a href="mailto:skw@hplb.hpl.hp.com"><skw@hplb.hpl.hp.com></a></dd>
<dd>Mark Jones, AT&T Labs <a href="mailto:jones@research.att.com"><jones@research.att.com></a></dd>
<dt>Contributors:</dt>
<dd>Mark Baker, formerly of Sun Microsystems Inc. <a href="mailto:mark.baker@canada.sun.com"><mark.baker@canada.sun.com></a></dd>
<dd>Martin Gudgin, formerly of DevelopMentor <a href="mailto:marting@develop.com"><marting@develop.com></a></dd>
<dd>Oisin Hurley, Iona <a href="mailto:ohurley@iona.com"><ohurley@iona.com></a></dd>
<dd>Marc Hadley, Sun Microsystems Inc. <a href="mailto:marc.hadley@uk.sun.com"><marc.hadley@uk.sun.com></a></dd>
<dd>John Ibbotson, IBM Corporation <a href="mailto:john_ibbotson@uk.ibm.com"><john_ibbotson@uk.ibm.com></a></dd>
<dd>Scott Isaacson, Novell Inc. <a href="mailto:SISAACSON@novell.com"><SISAACSON@novell.com></a></dd>
<dd>Yves Lafon, W3C <a href="mailto:ylafon@w3.org"><ylafon@w3.org></a></dd>
<dd>Jean-Jacques Moreau, Canon <a href="mailto:moreau@crf.canon.fr"><moreau@crf.canon.fr></a></dd>
<dd>Henrik Frystk Nielsen, Microsoft Corporation <a href="mailto:frystyk@microsoft.com"><frystyk@microsoft.com></a></dd>
<dd>Krinshna Sankar, Cisco Systems <a href="mailto:ksankar@cisco.com"><ksankar@cisco.com></a></dd>
<dd>Nick Smilonich, Unisys <a href="mailto:nick.smilonich@unisys.com"><nick.smilonich@unisys.com></a></dd>
<dd>Lynne Thompson, Unisys <a href="mailto:Lynne.Thompson@unisys.com"><Lynne.Thompson@unisys.com></a></dd>
</dl>
<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
© 2003 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
(<a href="http://www.lcs.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,<a
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software">software
licensing</a> rules apply.</p></div><hr><div>
<h2><a name="abstract">Abstract</a></h2>
<p>This document describes an Abstract Model of XML Protocol.</p>
<p>The challenge of crafting a protocol specification is to create
a description of behaviour that is not tied to any particular
approach to implementation. There is a need to abstract away from
some of the messy implementation details of buffer management, data
representation and specific APIs. However, in order to describe the
behaviour of a protocol one has to establish a set of (useful)
concepts that can be used in that description. An abstract model is
one way to establish a consistent set of concepts. An abstract
model is a tool for the description of complex behaviour — it
is not a template for an implementation... although it should not
stray so far away from reality that it is impossible to recognise
how the required behaviours would be implemented.</p>
</div><div>
<h2><a name="status">Status of this Document</a></h2>
<p>
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status
of this document series is maintained at the W3C.</p>
<p>
This W3C Working Draft (WD) of the XML Protocol Abstract Model has been
produced by the XML Protocol Working Group (WG), which is part of the
<a href="http://www.w3.org/2002/ws/Activity">Web Services Activity</a>.</p>
<p>
<b>The WG has decided to discontinue work on the Abstract Model, and on
this document. The WG developed the Abstract Model to provide a framework
for evaluating candidate protocols and for reasoning about the development
of the protocol itself. The WG believes the Abstract Model has well served
its purpose in this regard, and it no longer intends to do any further work
on the model.</b></p>
<p>
This document represents the contents of the first Abstract Model WD
(http://www.w3.org/TR/2001/WD-xmlp-am-20010709/) plus some small changes.
This document contains various open questions, however the WG does not
intend to answer them directly although answers may be found in other
documents produced by the WG.</p>
<p>
This document uses the term "XML Protocol", or the short form "XMLP", to
refer to the protocol being modelled.</p>
<p>Patent disclosures relevant to this specification may be found on the
Working Group's <a rel="disclosures" href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent disclosure page</a>.</p>
<p>The WG has decided to discontinue work on this document and feedback can be
sent to <a href="mailto:xmlp-comments@w3.org">xmlp-comment@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">archived</a> public list); however, the WG does not intend to respond to such feedback.</p>
<p>
This is a draft document and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use W3C Working Drafts
as reference material or to cite them as other than "work in progress". A
list of all W3C technical reports can be found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>
</div>
<div class="toc">
<h2><a name="contents">Table of Contents</a></h2>
<p class="toc">1 <a href="#Sec1">Introduction</a><br>
1.1 <a href="#Sec1.1">Definition of Terms</a><br>
2 <a href="#Sec2">XML Protocol Abstract Model Overview</a><br>
3 <a href="#Sec3">XML Protocol Layer Service Definition</a><br>
3.1 <a href="#Sec3.1">XMLP_UnitData Operation</a><br>
3.1.1 <a href="#Sec3.1.1">Correlation at Sending and Receiving XML Protocol Applications</a><br>
3.1.2 <a href="#Sec3.1.2">XMLP_UnitData Operation through Intermediaries</a><br>
3.1.3 <a href="#Sec3.1.3">Message Correlation at Intermediary XML Protocol Applications</a><br>
3.2 <a href="#Sec3.2">Operation Parameters</a><br>
4 <a href="#Sec4">XML Protocol Applications and Modules</a><br>
4.1 <a href="#Sec4.1">XML Protocol Message Routing and Targeting (aka Naming and Addressing :-))</a><br>
4.2 <a href="#Sec4.2">XML Protocol Modules and Message Processing</a><br>5 <a href="#Sec5"> Underlying Protocol Bindings</a><br>
5.1 <a href="#Sec5.1">Binding Service Model</a><br>
5.1.1 <a href="#Sec5.1.1">Introduction</a><br>
5.1.2 <a href="#Sec5.1.2"> Service Primitives</a><br>
5.1.2.1 <a href="#Sec5.1.2.1">Message Exchange</a><br>
5.1.2.2 <a href="#Sec5.1.2.2">Message Correlation</a><br>
5.1.2.3 <a href="#Sec5.1.2.3">Errors</a><br>
5.1.3 <a href="#Sec5.1.3">Message Exchange Patterns</a><br>
5.1.3.1 <a href="#Sec5.1.3.1">One Way Message</a><br>
5.1.3.2 <a href="#Sec5.1.3.2">Request Response</a><br>
5.1.3.3 <a href="#Sec5.1.3.3">Request and n Responses</a><br>
5.1.4 <a href="#sec5.1.4">Sample Mappings</a><br>
5.1.4.1 <a href="#Sec5.1.4.1">HTTP</a><br>
5.1.4.2 <a href="#Sec5.1.4.2">SMTP</a><br>
5.1.5 <a href="#Sec5.1.5">Binding Considerations</a><br>
5.2 <a href="#Sec5.2">BindingContext</a><br>
5.3 <a href="#Sec5.3">Attachment of Arbitrary Content</a><br>
6 <a href="#Sec6">References</a><br>
7 <a href="#Acknowledgements">Acknowledgements</a><br>
</p></div>
<hr>
<div class="body">
<div class="div1">
<h2><a name="Sec1"></a>1 Introduction</h2>
<p>An abstract model is a useful means to develop a description of
a system. It abstracts away from practical details such as specific
API definitions, data representation, and buffer management. It
provides a way to give a precise description of the externally
visible behaviour without being prescriptive of implementation
architecture.</p>
<p>This document is intended to serve as an overview and
introduction to the XML Protocol and its framework.</p>
<p>
<a href="#Sec2"><b>2 XML Protocol Abstract Model Overview</b></a> presents an overview of the abstract model</p>
<p>
<a href="#Sec3"><b>3 XML Protocol Layer Service Definition</b></a> presents a model for the services provided by the XML
protocol layer to XML protocol applications.</p>
<p>
<a href="#Sec4"><b>4 XML Protocol Applications and Modules</b></a> presents a model for the extensible processing of XML
protocol messages. </p>
<p>
<a href="#Sec5"><b>5 Underlying Protocol Bindings</b></a> presents a model for the binding of XML protocol to
underlying protocol layers.</p>
<div class="div2">
<h3><a name="Sec1.1"></a>1.1 Definition of Terms</h3>
<p>This document makes use of terms defined in the <a href="#XMLPReqs">[XMLPReqs]</a>. Additional terms introduced in
this document are defined locally in this section, however, in the
long term we anticipate that they will be incorporated into a
single glossary for all documents produced by the WG.</p>
<table cellpadding="2" cellspacing="0" width="100%" border="1"
summary="definitions of three terms not introduced in requirements document">
<colgroup span="2" valign="top"><col width="15%"><col width="85%"></colgroup>
<tr>
<td id="XMLPApp"><b>XMLP Application</b></td>
<td>
<p>A client or user of the services
provided by the <a href="#XMLPLayer">XML Protocol Layer</a>. An XML
Protocol Application may act in the initiating or responding role
with respect to two-way request response operations and in the
sending or receiving roles with respect to one-way operations. XML
Protocol Applications may also act in an intermediary role with
respect to both two-way and one-way operations.</p>
<p>
<a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g410">XML
Protocol Handlers</a> are encapsulated within XML Protocol
Applications.</p>
</td>
</tr>
<tr>
<td id="XMLPLayer"><b>XMLP Layer</b></td>
<td>
<p>The XML Protocol Layer is an
abstraction that provides services or operations that transfers
packages of <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g400">XML
Protocol Blocks</a> between peer <a href="#XMLPApp">XML Protocol
Applications</a> via zero or more <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g140">XML
Protocol Intermediaries</a>.</p>
</td>
</tr>
<tr>
<td id="XMLPOperation"><b>XMLP Operation</b></td>
<td>
<p>A primitive capability or service
offered by the <a href="#XMLPLayer">XML Protocol Layer.</a> The XML
Protocol Layer supports 3 operations described in detail in <a href="#Sec3"><b>3 XML Protocol Layer Service Definition</b></a>. XMLP Operations are modelled as
sequences of events crossing the layer boundary between <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g300">XML
Protocol Processors</a> and <a href="#XMLPApp">XML Protocol
Applications</a>.</p>
</td>
</tr>
</table>
</div>
</div>
<div class="div1">
<h2><a name="Sec2"></a>2 XML Protocol Abstract Model Overview</h2>
<p>
<a href="#Fig2.1">Figure 2.1</a> below presents a simple case of
the XML Protocol abstract model. Hosts I and V each contain
XML protocol application components, which <em>use</em> the services
of the XML protocol layer, and XML protocol layer components
which <em>provide</em> the services of the XML protocol layer. The
services of the XML protocol layer are abstracted at the upper
layer boundary as a single operation, XMLP_UNITDATA which is
described in detail in <a href="#Sec3"><b>3 XML Protocol Layer Service Definition</b></a>.</p>
<img src="Figure2-1.png" alt="Figure 2.1 Model of Simple Case without Intermediaries." id="Fig2.1">
<p class="caption">Figure 2.1 Model of Simple Case without Intermediaries.</p>
<p>
<a href="#Fig2.2">Figure 2.2</a> below shows 5 hosts in a more
complex case of the XML Protocol abstract model. Hosts I, III
and V each contain XML protocol application components. Hosts
II and IV are intermediaries that operate within underlying
protocol layers such as HTTP proxies and SMTP message routers.</p>
<img src="Figure2-2.png" alt="Figure 2.2 XML Protocol Model Overview" id="Fig2.2">
<p class="caption">Figure 2.2 XML Protocol Model Overview</p>
<p>
<a href="#Fig2.2">Figure 2.2</a> can be used to
discuss a number of message exchange scenarios. For example, the
XML protocol Processor at Host III is bound to two, possibly
different, underlying protocols. It could serve merely as a
'helper' to transition an XML protocol message from one underlying
protocol to another in circumstances where the initiating processor
is bound to a different underlying protocol infrastructure than the
receiving or responding node, say Host V in <a href="#Fig2.2">
figure 2.2</a>. A similar scenario arises if Host III is part of an
XML Protocol Firewall that controls the ingress and egress of
messages from a given organisation. In both these circumstances the
XML Protocol Handler(s) within the XML protocol application at
Host III need not be present.</p>
<p>If we turn our attention to the operation of the
XML protocol applications above the XML protocol layer boundary, we
have a scenario in which the application at Host I has some XML
protocol blocks to deliver to Host V. In addition the application
at Host I needs to trigger Intermediary functionality at Host III
by the inclusion of several XML Protocol Blocks. "XML Protocol
Block 1" is intended for "XML protocol handler (e) " within the
application on Host V. Block 2 is intended for handler (h)
and handler (c) which replaces Block 2 with Block 3.
Also, the XML protocol application at Host III inserts Block 4 into
the message forwarded from Host III to Host V. Blocks 3 and 4
are intended for handlers (f) and (g).</p>
</div>
<div class="div1">
<h2><a name="Sec3"></a>3 XML Protocol Layer Service Definition</h2>
<p>This section focuses on the definition of an
abstract interface between the XML protocol applications and the
XML protocol layer. It needs to be remembered that the layer
interface described in this section is abstract - its purpose is to
enable description, not to constrain implementation.</p>
<p>The services provided by the XML protocol layer are
modeled a single operation. XMLP_UNITDATA provides services to
sending, intermediary and receiving XML protocol applications.</p>
<div class="div2">
<h3><a name="Sec3.1"></a>3.1 XMLP_UnitData Operation</h3>
<p>XMLP_UnitData is a best effort one-way message transfer
operation with message correlation. Multiple message transfer
operations can be correlated in various ways to form message
exchange patterns like request/response, and long-lived
dialogs.</p>
<p>The XMLP_UnitData operation is modeled by four primitives
(events). Each primitive models a transmission, reception or status
event at interface between an XML protocol application and an
XML protocol processor:</p>
<p class="code">
<code>XMLP_UnitData.send( To, [ImmediateDestination], Message, [Correlation], [BindingContext]);</code>
</p>
<p class="code">
<code>XMLP_UnitData.receive( [To], [From], Message, [Correlation], [BindingContext]);</code>
</p>
<p class="code">
<code>XMLP_UnitData.status( [From], Status, [BindingContext]);</code>
</p>
<p class="code">
<code>XMLP_UnitData.forward( [ImmediateDestination], Message, [BindingContext]);</code>
</p>
<p class="code">
<code>All parameters are detailed in </code>
<a href="#Sec3.2"><b>3.2 Operation Parameters</b></a>.</p>
<p>Conceptually the XMLP_UnitData operation encapsulates the
transmission of an XML protocol message from a sending XML protocol
application to a receiving XML protocol application. The principal
conceptual difference between sending and forwarding an XML
protocol message is that, from a message correlation point of view,
sending generates a new message whereas forwarding passes on an
existing message. Conceptually the forwarded message is the same
message as previously received although the action of intermediary
processing may have changed the value of the message.</p>
<p>
<a href="#Fig3.1">Figure 3.1</a> below illustrates the normal
use of these primitive at the sending and receiving XML protocol
applications.</p>
<img src="Figure3-1.png" alt="Figure 3.1 XMLP_UNITDATA Operation" id="Fig3.1">
<p class="caption">Figure 3.1 XMLP_UNITDATA Operation</p>
<p>The operation is best effort which means that it can fail
silently with the loss of the message in transit. A lost
message may have been partially processed at an intermediary XML
protocol application. The success or failure of the operation is
reported via the XMLP_UnitData.status primitive. In some
circumstances it may only be possible to report that a message has
been sent. In other circumstances it may be possible to report that
a message has or has not been delivered to its ultimate
recipient.</p>
<p>
<a title="XMLP_UnitData.send" name="XMLP_UnitData.send"></a>
<b>XMLP_UnitData.send</b> is invoked by the sending XML protocol
application and directed at the local sending XML protocol
processor to start a one-way transfer operation.
</p>
<p>Upon receipt of this primitive by the sending XML protocol
processor an XML protocol message is transferred from the sending
XML protocol processor toward the receiving XML protocol processor
(possibly via intermediary XML protocol processors).</p>
<p> This primitive differs from the .<a href="#XMLP_UnitData.forward">forward</a>
primitive in that it is used by the initial sender of an XML protocol message to send a new
message.</p>
<p>
<a title="XMLP_UnitData.receive" name="XMLP_UnitData.receive"></a>
<b>XMLP_UnitData.receive</b> is invoked by the receiving XML
protocol processor and directed at a local receiving
XML protocol application to deliver a received XML protocol
message.
</p>
<p> This primitive is invoked as a result of the arrival of an XML
protocol message from the sending XML protocol processor (via the
underlying protocol layers).</p>
<p>
<a title="XMLP_UnitData.status" name="XMLP_UnitData.status"></a>
<b>XMLP_UnitData.status</b> is used to report on the delivery status
of the operation to the sending XML protocol application. This
primitive may be used to report to the sending XML protocol
application on the success or failure to send and deliver a message
to the receiving XML protocol application. In general, it is not
possible to assert that a message has been delivered to the
receiving XML protocol application without engaging in further
interactions. With care it is possible to assert definite failure
to deliver provided that circumstances are such that there is no
possibility of subsequent delivery. From the point-of-view of the
initiating XML application the operation has completed once this
primitive has been invoked.</p>
<p>
<a title="XMLP_UnitData.forward" name="XMLP_UnitData.forward"></a>
<b>XMLP_UnitData.forward</b> is invoked by an intermediary XML
protocol application once it has completed intermediary processing
of a message in transit and directed at the local intermediary XML
protocol processor.
</p>
<p> In the event of success the message is forwarded to its next
destination, as designated by the ImmediateDestination parameter if
given. Alternatively an implementation or configuration dependent
method may be used to select the next recipient of the message
along a path.</p>
<p> In the event of failure, the message in transit is discarded. A
correlated fault message may be generated by the intermediary XML
protocol application and sent toward the originator of the failed
message.</p>
<p>This primitive differs from the <a href="#XMLP_UnitData.send">
.send</a> primitive in that it is used by an intermediary XML
protocol application to forward an existing XML protocol message
received by the intermediary XML protocol application.</p>
<p>An XML protocol application may engage in multiple concurrent
operations with the same or different intermediary and/or receiving
XML protocol applications. These concurrent operations are
independent and the order in which they are processed by the
receiving and intermediary applications may be different from the
order in which they are invoked or complete at the sending XML
protocol application. </p>
<div class="div3">
<h4><a name="Sec3.1.1"></a>3.1.1 Correlation at Sending and Receiving XML Protocol Applications</h4>
<p>The <a href="#Correlation">Correlation</a> parameter provides a
general mechanism by which richer message exchange patterns such as
request-response and request/multi-response can be derived on top
of the one-way message exchange pattern of the XMLP_UnitData
operation. The mechanism by which correlation is determined
is <em>not</em> specified in this abstract model.</p>
<p>Message correlation may be determined through:</p>
<ul>
<li>
<p>the exploitation of features in the underlying protocol eg. the
request/response nature of HTTP;</p>
</li>
<li>
<p>mechanism introduced either by the XMLP processor to operate
across multiple possible underlying protocols.</p>
</li>
<li>
<p>mechanism introduced by a binding to a particular underlying
protocol within the domain of the underlying protocols own header
extension mechanism.</p>
</li>
</ul>
<p>When included in an <a href="#XMLP_UnitData.send">
XMLP_UnitData.send</a> primitive <a href="#Correlation.MessageRef">
Correlation.MessageRe</a>f indicates that the XML protocol message
being sent is a direct consequence of the processing of an XML
protocol message previously received by the sending XML protocol
application and referenced locally by <a href="#Correlation.MessageRef">Correlation.MessageRef</a>.</p>
<p>Likewise, when included in an <a href="#XMLP_UnitData.receive">
XMLP_UnitData.receive</a> primitive <a href="#Correlation.MessageRef">Correlation.MessageRef</a> indicates
that the message being received is a direct consequence of the
processing of a XML protocol message previously sent by the
receiving XML protocol application and referenced locally by <a href="#Correlation.MessageRef">Correlation.MessageRef</a>.</p>
<p>Failures that arise during message processing at the recipient
or at intermediary XML protocol applications may result in the
generation of fault messages directed toward the originator of the
message whose processing gave rise to the fault. Such fault
messages are a direct consequence of the faulted message and this
should be indicated through the use of the <a href="#Correlation">
Correlation</a> parameter.</p>
</div>
<div class="div3">
<h4><a name="Sec3.1.2"></a>3.1.2 XMLP_UnitData Operation through Intermediaries</h4>
<p>Conceptually an XML protocol intermediary does not generate a
new XML protocol message, it operates on an XML protocol message in
transit. Thus the received message and the forwarded message are
regarded as the same message although the intermediary may change
the value of the message. </p>
<p>
<a href="#Fig3.2">Figure 3.2</a> shows the normal behaviour of
an XML_UnitData operation through an intermediary in the absence of
fatal failures. The three vertical lines represent the local XML
protocol layer boundaries and the small arrows above denote the
up/down orientation of the boundary. <a href="#Fig3.3">Figure
3.3</a> below shows an alternate representation of the same
scenario.</p>
<p>The scenario depicted in figures <a href="#Fig3.2">3.2</a>and <a href="#Fig3.3">3.3</a>. show just a single intermediary interposed
in the operation however the principle extends to an arbitrary
number of intermediaries.</p>
<img src="Figure3-2.png" alt="Figure 3.2 Normal XMLP_UnitData operation through an Intermediary" id="Fig3.2">
<p class="caption">Figure 3.2 Normal XMLP_UnitData operation through an Intermediary</p>
<img src="Figure3-3.png" alt="Figure 3.3 Normal XMLP_UnitData operation through and Intermediary (alternate treatment)" id="Fig3.3">
<p class="caption">Figure 3.3 Normal XMLP_UnitData operation through and Intermediary (alternate treatment)</p>
<p>It is worth noting that the <a href="#XMLP_UnitData.status">
XMLP_UnitData.status</a> is generated from within the XML protocol
layer. It may indicate anything from the mere fact that the message
has been sent or forwarded by the sending node; that its has been
received and/or sent from the intermediary node; or that it has
indeed been delivered to the ultimate recipient node. What it means
in a given circumstance will depend upon the capabilities of the
underlying communications protocols used to construct the message
path. The strongest thing that it can indicate is the failure to
deliver an XML protocol message to its ultimate recipient.</p>
</div>
<div class="div3">
<h4><a name="Sec3.1.3"></a>3.1.3 Message Correlation at Intermediary XML Protocol Applications</h4>
<p>The <a href="#Correlation.MessageRef">Correlation.MessageRef</a>
sub-field of the optional <a href="#Correlation">
Correlation</a> parameter on a <a href="#XMLP_UnitData.receive">
XMLP_UnitData.receive</a> primitive carries a local abstract
reference to an XML protocol message that was previously forwarded
by this intermediary XML protocol application. The current message
is a direct consequence of the processing of that earlier forwarded
message.</p>
<p>Typically this will arise when an application level response
travels along a path that passes through one or more of the same
intermediary XML protocol applications that the corresponding
request passed through earlier.</p>
</div>
</div>
<div class="div2">
<h3><a name="Sec3.2"></a>3.2 Operation Parameters</h3>
<p>This section describes the operation parameters used in the
operation primitives described above.</p>
<table cellpadding="2" cellspacing="0" width="100%" border="1"
summary="descriptions of eleven operations parameters">
<colgroup span="2" valign="top"><col width="15%"><col width="85%"></colgroup>
<tr>
<td id="To"><b>To</b></td>
<td>
<p>An abstract reference that denotes the XML protocol application
that a message was originally sent to by the initiating or sending
XML protocol application.</p>
</td>
</tr>
<tr>
<td id="From"><b>From</b></td>
<td>
<p>An abstract reference denotes the sending XML protocol application in
<a href="#XMLP_UnitData.receive">.receive</a> primitives.</p>
<p> In <em>.receive</em> primitives this parameter makes the
identity of the sending/initiating XML protocol application
available to the receiving/responding XML protocol
application.</p>
<span class="ednote"><b>Editorial note </b>[Intermediaries may obscure this or we may require that they don't... discuss!]</span>
<p>In the <em>XMLP_UnitData.status</em> primitive, this parameter conveys the identity of the XML protocol application to which an XML protocol message was sent after any redirections imposed by underlying protocols. NB. Further redirections may occur that cannot be reported.</p>
<span class="ednote"><b>Editorial note </b>[Again possibly obscured by intermediaries...]</span>
</td>
</tr>
<tr>
<td id="ImmediateDestination"><b>ImmediateDestination</b></td>
<td>
<p>An identifier that denotes the
immediate destination of an XML protocol message. If this parameter
is unspecified, the default value is implementation and
configuration dependent.</p>
<p>This parameter enables sending and intermediary XML
protocol applications to address the message to the next
intermediary on route.</p>
</td>
</tr>
<tr>
<td id="Message"><b>Message</b></td>
<td>
<p>An abstraction of an XML protocol
message exchanged between sending and receiving XML protocol
applications. An XML protocol message has the following
sub-fields: Message.Faults; Message.Blocks; and
Message.Attachments. </p>
</td>
</tr>
<tr>
<td id="Message.Faults"><b>Message.Faults</b></td>
<td>
<p>An abstraction of a collection of XML
protocol faults carried in an XML protocol message that is
correlated with the XML protocol message whose processing gave rise
to one or more faults. Such a message may arise at an intermediary
or at the ultimate recipient.</p>
</td>
</tr>
<tr>
<td id="Message.Blocks"><b>Message.Blocks</b></td>
<td>
<p>An abstraction of the XML
protocol blocks within an XML protocol message which are
intended to be processed by intermediaries or the ultimate
recipient.</p>
</td>
</tr>
<tr>
<td id="Message.Attachments"><b>Message.Attachments</b></td>
<td>
<p>An abstraction of the a collection of
arbitrary attachments being transferred as part of an XML protocol
message. These attachments are opaque bytes as far as XML protocol
processing elements are concerned.</p>
<p>From the point-of-view of abstract service definition the actual
mechanism used to transfer attachments is immaterial, however
particular bindings may employ more efficient mechanisms than
others.</p>
<span class="ednote"><b>Editorial note </b>[NB. This places an obligation on XML protocol
binding specifications to specify how attachments are to be
carried.]</span>
</td>
</tr>
<tr>
<td id="Correlation"><b>Correlation</b></td>
<td>
<p>An optional parameter used to express
local relationships between XML protocol messages.</p>
<p>At present only a single subfield, Correlation.MessageRef is
defined, however it is conceivable that other subfields may be
defined in future, eg. Correlation.MsgSequence to distinguish
between and potentially order n multiple messages that arise from
the same source as a direct consequence of the current
message.</p>
</td>
</tr>
<tr>
<td id="Correlation.MessageRef"><b>Correlation.MessageRef
</b></td>
<td>
<p>An abstraction of a local reference to
the local abstraction of an XML protocol message the processing of
which the current XML protocol message is a direct consequence. </p>
<p>In <a href="#XMLP_UnitData.send">XMLP_UnitData.send</a>
primitives, the value of this parameter references an XML protocol
message previously received by the sending XML protocol
application.</p>
<p>In <a href="#XMLP_UnitData.receive">XMLP_UnitData.receive</a>
primitives, the value of this parameter references an XML protocol
message previously sent or forwarded by the receiving
application.</p>
</td>
</tr>
<tr>
<td id="BindingContext"><b>BindingContext
</b></td>
<td>
<p>This parameter references an abstract structure that carries
information pertinent to the underlying protocol binding(s). For
example it may carry certificates, ids and passwords to be used by
the sending/initiating XML protocol application to authenticate
itself and/or to establish a secure channel. At the responding XML
protocol application it may carry the authenticated id of the
principal on whose behalf the operation is being conducted.</p>
<p>If the information present in the BindingContext is inadequate
for the execution of a given service primitive the invocation of
that primitive will fail with a result that indicates why progress
was not possible.</p>
<p>BindingContext is optional and if not supplied the local default
binding will be used. In the case of multiple bindings being
available, inbound BindingContext indicates how an inbound message
was received and outbound BindingContext constrains the choice of
binding used for a given operation.</p>
<p>BindingContext is discussed further in <a href="#Sec5.2"><b>5.2 BindingContext</b></a>.</p>
<span class="ednote"><b>Editorial note </b>[NB This concept places another obligation on
XML protocol binding specifications in that they must enumerate
what binding specific information they require in an outbound
BindingContext and what binding specific information they provide
in inbound BindingContexts.]</span>
</td>
</tr>
<tr>
<td id="Status.Parameter"><b>Status</b></td>
<td>
<p>In <a href="#XMLP_UnitData.status">
.status</a> primitives this parameter indicates the disposition of
the request operation which may be: <em>MessageSent,
MessageDelivered, Unknown</em> and <em>
FailedAtIntermediary</em>. The interpretation of a status value may
be augmented by information carried in the <em>BindingContext</em>. </p>
</td>
</tr>
</table>
</div>
</div>
<div class="div1">
<h2><a name="Sec4"></a>4 XML Protocol Applications and Modules</h2>
<span class="ednote"><b>Editorial note </b>There is a significant debate over terms and
concepts around Modules, Handlers, Targeting and Message routing.
At the time of this draft the discussion is still open and this
section will be updated to reflect any consensus arising from that
discussion.</span>
<p>An XML protocol application is the logic at an XML processor
that makes use of the core messaging services of the XML protocol.
XML protocol applications may initiate, respond or act as
intermediaries in XML protocol operations. Logically, an XML
protocol application contains a number of XML protocol handlers
that are responsible for applying the processing rules associated
with XML protocol modules. The unit of exchange between XML
protocol handlers are XML protocol blocks.</p>
<p>XML protocol blocks are aggregated into XML protocol messages
and may be targeted at particular XML processors (see <a href="#Sec4.2"><b>4.2 XML Protocol Modules and Message Processing</b></a>). XML protocol blocks are delivered
together with the rest of the XML protocol message which
encapsulates them (and its attachments if any) to the
targeted XML processor. The XML protocol application is then
responsible for identifying and dispatching the appropriate XML
protocol handlers. Generally, the dispatch to a handler will
be determined by the presence of an associated block or blocks, but
not necessarily. Handler d in <a href="#Fig2.2">Figure
2.2</a> illustrates such a case.</p>
<img src="Figure4-1.png" alt="Figure 4.1 XML Protocol Application" id="Fig4.1">
<p class="caption">Figure 4.1 XML Protocol Application</p>
<p>Each handler may succeed or fail fatally. It is the
responsibility of the XML protocol application to determine the
overall result of the actions of any XML protocol handlers it
invokes and to augment any Faults structure carried in the ongoing
message. In cases where there are multiple influences on the
ImmediateDestination, it is also the responsibility of the XML
protocol application to resolve any conflicts.</p>
<div class="div2">
<h3><a name="Sec4.1"></a>4.1 XML Protocol Message Routing and Targeting (aka Naming and Addressing :-))</h3>
<span class="ednote"><b>Editorial note </b>Needs to use some terms here that arise from the
intermediaries thread Martin started</span>
<p>An XML protocol message path can be viewed as the sequence of
handlers that an XML protocol message passes through between
initiating/sending XML protocol application and receiving
responding XML protocol application. With reference to <a href="#Fig2.2">figure 2.2,</a> the diagram in <a href="#Fig4.2">figure 4.2</a> depicts the message path of the
corresponding XML protocol message under the XML_UnitData
operation.</p>
<img src="Figure4-2.png" alt="Figure 4.2 XML Protocol Message Path" id="Fig4.2">
<p class="caption">Figure 4.2 XML Protocol Message Path</p>
<p>The path in <a href="#Fig4.2">figure 4.2</a> shows sequential
handler processing at the sending node, Node I, while the handler
processing at Nodes III and V is concurrent (at least logically).
Combinations of handlers that can be invoked concurrently from
within an XML protocol application are said to be mutually
orthogonal.</p>
</div>
<div class="div2">
<h3><a name="Sec4.2"></a>4.2 XML Protocol Modules and Message Processing</h3>
<p>XML protocol modules are the unit of extension within the XML
protocol. An XML protocol module encapsulates the syntactic
constructs of an extension, known as XML protocol blocks, and the
behavioural rules associated with the generation and processing of
an XML protocol block. The abstraction for the processing
and/or logic defined by an XML protocol module is called an XML
protocol handler.</p>
<p>The SOAP 1.1 specification (section 2) states: "Processing
a message or a part of a message requires that the SOAP processor
understands, among other things, the exchange pattern being used
(one way, request-response, multicast, etc.), the role of the
recipient in that pattern, the employment (if any) of RPC
mechanisms such as the one documented in section 7, the
representation or encoding of data, as well as other semantics
necessary for correct processing." An XML protocol module is
the locus for understanding blocks associated with that
module. A given message may employ the services of many
modules, both generic (e.g., security, caching, compression,
transactions, etc.) and application-specific.</p>
<p>The following list provides an initial set of concepts which
capture and slightly refine the SOAP message processing
model. A comparison of each concept with SOAP is also
provided for reference.</p>
<ol>
<li>
<p>An XML Protocol message consists of
a set of zero or more blocks.</p>
<span class="ednote"><b>Editorial note </b>SOAP: Similar. Blocks correspond to header or body entries. SOAP groups header entries into an optional Header element and body entries into an obligatory Body element.</span>
</li>
<li>
<p>Each block has the following
sub-fields: <em>Block.Id</em>, <em>Block.Actor</em>, and <em>
Block.MustUnderstand</em>. Block.Id is an optional identifier
that identifies the block for the purposes of reference by other
blocks. Block.Actor identifies the XMLP processor that is
intended to process the block. Block.MustUnderstand specifies
whether the intended semantics of the block must be carried
out.</p>
<span class="ednote"><b>Editorial note </b>SOAP: SOAP does
not specify whether an actor URI is to be interpreted extensionally
(naming a particular node) or intensionally (describing a node or
group of nodes that satisfy some property). Special reserved
URI's describe nodes which are encountered next or last.
Beyond the reserved URI's, there is no particular semantics
associated with an actor URI. Semantically, the URI's can
signify a processor that supports a given application, module or
capability, or it can describe a destination, node or
location. This flexibility is preserved in XMLP.</span>
</li>
<li>
<p>The fully qualified name of the top
element of a block identifies the block.</p>
<span class="ednote"><b>Editorial note </b>SOAP: SOAP identifies
blocks by the fully qualified element name. The block can
(but need not) be mapped to some appropriate handler. Other
schemes have also been suggested. For example, an attribute
could name a module which would take responsibility for selecting
the handler to invoke.</span>
</li>
<li>
<p>The following values for Block.Actor
have special significance: <code>Next</code>, <code>Final</code>, and <code>
None</code>.; Next matches the next processor. Final
matches the final processor. None is for untargeted blocks
which may be referenced by other blocks.</p>
<p>An empty actor defaults to Final. An untargeted block
marked with <code>None</code> is useful for
declarative information that is referenced by another block or
blocks. It is guaranteed not to be removed and can even be
referenced by blocks which are targeted at different
processors.</p>
<span class="ednote"><b>Editorial note </b>SOAP: An
empty SOAP actor in a header "indicates that the recipient is the
ultimate destination of the SOAP message," and a "body entry is
semantically equivalent to a header entry intended for the default
actor." This is what <code>Final </code> designates. The intended (final) processor must
recognize itself as such. <code>Next </code> has the same interpretation as
the SOAP URI, <code>http://schemas.xmlsoap.org/soap/actor/next</code> SOAP
forces the actor for body entries to be the final processor.
SOAP permits the inclusion of blocks for which there do not turn
out to be any actors that match along the message path; and even if
an actor URI matches a given processor, the processor may determine
that no behaviour is associated with the block. The value
None, on the other hand, is a stronger statement on the part of the
sender that signifies that no processor will qualify as a matching
actor.</span>
</li>
<li>
<p>When a block is selected for
processing at an intermediary, the block is removed from the
envelope. A handler may add zero or more blocks. Blocks
which are merely referenced are not removed.</p>
<span class="ednote"><b>Editorial note </b>SOAP: SOAP
doesn't allow body entries to be processed at intermediaries and
hence they are never removed at an intermediary.</span>
</li>
<li>
<p>The XML Protocol blocks are ordered
within the envelope. This order is followed by each processor
as it selects and processes blocks, yielding a limited facility for
specifying sequential constraints. Two alternatives are
available for more complex orderings and constraints.
Hierarchical constraints can be achieved by syntactically scoping
blocks inside one another. Finally, blocks can be
incorporated by reference using the "<code>id</code>" and "<code>href</code>" attribute mechanism.; Using these techniques, more elaborate "manifest" blocks which direct the
processing of other blocks can be designed. From the processor's point of view, only the outermost element of the block is seen.</p>
<span class="ednote"><b>Editorial note </b>SOAP: Header
entries can be referenced via links from other headers. If
they have no actor (targeted at the final destination), they will
not be removed by any intermediaries. Using that mechanism,
headers can be effectively shared among modules, even at different
nodes. The actor-less headers are interpreted as relevant to
the final processor, even though they may not be. The body
can only be targeted at the final procesor.</span>
</li>
<li>
<p>The processing of a block by a
handler may result in a fault or a successful evaluation. A
fault terminates processing of the block and message and causes a
return message containing the fault to be generated if a return
path is available. Rather than fatally faulting, it is also
possible for a handler to insert a block targeted to another
destination e.g., the final destination). This block can
contain status information, non-fatal errors, or other results that
can be further processed, incorporated into a return value,
etc.</p>
<span class="ednote"><b>Editorial note </b>SOAP: Similar.
</span>
</li>
</ol>
</div>
</div>
<div class="div1">
<h2><a name="Sec5"></a>5 Underlying Protocol Bindings</h2>
<p>It is the intent that the XML protocol be capable of being bound
to a variety of underlying communication protocols. The XML
protocol working group will define a binding to HTTP. It is
anticipated that others will create bindings to SMTP, TCP, SSL,
BEEP and others.</p>
<div class="div2">
<h3><a name="Sec5.1"></a>5.1 Binding Service Model</h3>
<span class="ednote"><b>Editorial note </b>This entire subsection is new and has not be
subject of significant debate. It should be regarded as a work in
progress</span>
<div class="div3">
<h4><a name="Sec5.1.1"></a>5.1.1 Introduction</h4>
<p>This section presents an abstract service model that XML
protocol bindings will supply to the upper XML protocol layer. The
intent is to describe the interactions between the XML protocol
processor and underlying protocol bindings and to demonstrate how
these interactions are choreographed to enable multiple message
exchange patterns. This model is intended to provide a framework in
which the development of concrete binding specifications can be
discussed. This is not intended as an API specification.</p>
<p>The diagram below shows a logical layered view of the binding
model with the XML protocol processor being bound to four
underlying transports.</p>
<img src="Figure5-1.png" alt="Figure 5.1 Binding Model" id="Fig5.1">
<p class="caption">Figure 5.1 Binding Model</p>
<p>This document concerns itself with the interactions at the solid
black line between the XML protocol processor and a given
binding.</p>
<p>Note that, as shown, some bindings may be nested. e.g. a MIME
binding might be nested within a HTTP binding to allow additional
binary data to be sent along with (but outside) the XMLP
envelope.</p>
</div>
<div class="div3">
<h4><a name="Sec5.1.2"></a>5.1.2 Service Primitives</h4>
<div class="div4">
<h5><a name="Sec5.1.2.1"></a>5.1.2.1 Message Exchange</h5>
<p>There are two primitives associated with message exchange: <code>MSG.req</code> and <code>
MSG.ind</code>. A <code>MSG.req</code> primitive
is sent from the XML protocol processor to the binding in order to
cause the binding to send a message. A <code>
MSG.ind</code> primitive is sent from the binding to the XML
protocol processor to indicate arrival of a message.</p>
</div>
<div class="div4">
<h5><a name="Sec5.1.2.2"></a>5.1.2.2 Message Correlation</h5>
<p>In order to support message exchange patterns that are more
complex than the simplest one-way exchange, some form of message
correlation is required. For example, in a request-response message
exchange there must be some means of correlating the request with
the response. In this document a single instance of a message
exchange pattern is referred to as an XML protocol processor
operation or just operation for short.</p>
<p>There are four pairs of primitives associated with operation
delineation and hence message correlation:</p>
<ol>
<li>
<p>
<code>OP.start-req</code> and <code>OP.start-conf</code>
A <code>OP.start-req</code> primitive is sent
from the XML protocol processor to the binding to request
initialisation of a new correlated message exchange. The binding
responds with a <code>OP.start-conf</code>
primitive.</p>
</li>
<li>
<p>
<code>OP.start-ind</code> and <code>OP.start-resp</code>
A <code>OP.start-ind</code> primitive is sent
from the binding to the XMPL layer to indicate that a new
correlated message exchange is being requested. The XML protocol
processor responds with a <code>
OP.start-resp</code> primitive.</p>
</li>
<li>
<p>
<code>OP.end-req</code> and <code>OP.end-conf</code>
An <code>OP.end-req</code> primitive is sent
from the XML protocol processor to the binding to terminate a
correlated message exchange. The binding responds with an <code>OP.end-conf</code>primitive. Whilst the <code>OP.end-conf</code> is outstanding, the XML
protocol processor must be prepared to continue to receive <code>MSG.ind</code>s</p>
</li>
<li>
<p>
<code>OP.end-ind</code> and <code>OP.end-resp</code>
An <code>OP.end-ind</code> primitive is sent
from the binding to the XML protocol processor to indicate that a
correlated message exchange is to be terminated. No further <code>MSG.ind</code> will be delivered as part of the
corresponding operation, however the XML protocol processor
receiving the <code>OP.end-ind</code> primitive
may continue to issue <code>MSG.req</code>
primitives to complete operation in progress. Once all <code>MSG.req</code> primitives associate with the
operation have been issued the XML protocol processor concludes the
operation by with the invocation of an <code>
OP.end-resp</code> primitive."</p>
</li>
</ol>
<p>The actual correlation mechanism is underlying protocol and
implementation specific. e.g. A <code>
OP.start-conf</code> may carry some unique identifier that must be
provided with any subsequent <code>
MSG.req</code>(s) and is included with any subsequent <code>MSG.ind</code>(s).</p>
<p>There is no retained state within the binding between operations
although there may be during operations.</p>
</div>
<div class="div4">
<h5><a name="Sec5.1.2.3"></a>5.1.2.3 Errors</h5>
<p>The final primitive <code>ERR.ind</code> is
sent from the binding to the XML protocol processor when an error
occurs, e.g. if a <code>MSG.req</code> cannot be
honoured then an <code>ERR.ind</code> is
generated. Errors are correlated to a particular message exchange
using the mechanism described above.</p>
</div>
</div>
<div class="div3">
<h4><a name="Sec5.1.3"></a>5.1.3 Message Exchange Patterns</h4>
<p>The following sections illustrate the choreography of XML
protocol binding primitives for a number of different message
exchange patterns. These are intended to be illustrative rather
than proscriptive. In particular, in many cases either sender or
receiver might initiate the OP.end-req.</p>
<div class="div4">
<h5><a name="Sec5.1.3.1"></a>5.1.3.1 One Way Message</h5>
<p class="particpant">Sender</p>
<p>
<code>OP.start-req</code>, <code>OP.start-conf</code>, <code>
MSG.req</code>, <code>OP.end-req</code>, <code>OP.end-conf</code>.</p>
<p class="participant">Receiver</p>
<p>
<code>OP.start-ind</code>, <code>OP.start-resp</code>, <code>
MSG.ind</code>, <code>OP.end-ind</code>, <code>OP.end-resp</code>.</p>
<p class="participant">Comments</p>
<p>Note that depending on the underlying protocol the primitives at
sender and receiver may not operate in lock-step. In particular,
the <code>OP.start-ind</code> may not be
delivered to the receiving XML protocol processor until the sending
XML protocol processor has issued the <code>
MSG.req</code> or even the <code>
OP.end-req</code>. An alternative way of saying this is that a
binding may choose to delay making an underlying protocol
connection until a message needs to be sent.</p>
</div>
<div class="div4">
<h5><a name="Sec5.1.3.2"></a>5.1.3.2 Request Response</h5>
<p class="participant">Sender</p>
<p>
<code>OP.start-req</code>, <code>OP.start-conf</code>, <code>
MSG.req</code>, <code>MSG.ind</code>, <code>OP.end-req</code>, <code>
OP.end-conf</code>.</p>
<p class="participant">Receiver</p>
<p>
<code>OP.start-ind</code>, <code>OP.start-resp</code>, <code>
MSG.ind</code>, <code>MSG.req</code>, <code>OP.end-ind</code>, <code>
OP.end-resp</code>.</p>
</div>
<div class="div4">
<h5><a name="Sec5.1.3.3"></a>5.1.3.3 Request and <em>n</em> Responses</h5>
<p class="participant">Sender</p>
<p>
<code>OP.start-req</code>, <code>OP.start-conf</code>, <code>
MSG.req</code>, <code>MSG.ind</code>, <code>MSG.ind</code>, ..., <code>
OP.end-ind</code>, <code>OP.end-resp</code>.</p>
<p class="participant">Receiver</p>
<p>
<code>OP.start-ind</code>, <code>OP.start-resp</code>, <code>
MSG.ind</code>, <code>MSG.req</code>, <code>MSG.req</code>, ..., <code>
OP.end-req, OP.end-conf</code>.</p>
</div>
</div>
<div class="div3">
<h4><a name="sec5.1.4"></a>5.1.4 Sample Mappings</h4>
<div class="div4">
<h5><a name="Sec5.1.4.1"></a>5.1.4.1 HTTP</h5>
<p>The following tables show how the binding primitives might map
onto the HTTP protocol actions on the initiator and responder for a
request-response message exchange, time increases moving down the
tables.</p>
<table border="1" summary="binding primitives mapped onto HTTP protocol actions">
<caption>
Initiator
</caption>
<thead>
<tr>
<td rowspan="1" colspan="1">
Binding Primitive
</td>
<td rowspan="1" colspan="1">
Binding Action
</td>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1">OP.start-req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.start-conf</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">MSG.req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Send POST request</td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Receive POST results</td>
</tr>
<tr>
<td rowspan="1" colspan="1">MSG.ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-conf</td>
<td rowspan="1" colspan="1"> </td>
</tr>
</tbody>
</table>
<table border="1" summary="binding primitives mapped onto HTTP protocol actions">
<caption>
Responder
</caption>
<thead>
<tr>
<td rowspan="1" colspan="1">
Binding Primitive
</td>
<td rowspan="1" colspan="1">
Binding Action
</td>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Receive POST request</td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.start-ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.start-resp</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">MSG.ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">MSG.req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Send POST results</td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-resp</td>
<td rowspan="1" colspan="1"> </td>
</tr>
</tbody>
</table>
<p>The above assumes use of HTTP persistent connections.</p>
</div>
<div class="div4">
<h5><a name="Sec5.1.4.2"></a>5.1.4.2 SMTP</h5>
<p>The following tables show how the binding primitives might map
onto the SMTP protocol actions on the initiator and receiver for a
simple one-way message exchange, time increases moving down the
tables.</p>
<table border="1" summary="binding primitives mapped onto SMTP protocol actions">
<caption>
Initiator
</caption>
<thead>
<tr>
<td rowspan="1" colspan="1">
Binding Primitive
</td>
<td rowspan="1" colspan="1">
Binding Action
</td>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1">OP.start-req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Open SMTP session</td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.start-conf</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">MSG.req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Send mail message</td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-req</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Close SMTP session</td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-conf</td>
<td rowspan="1" colspan="1"> </td>
</tr>
</tbody>
</table>
<table border="1" summary="binding primitives mapped onto SMTP protocol actions">
<caption>
Responder
</caption>
<thead>
<tr>
<td rowspan="1" colspan="1">
Binding Primitive
</td>
<td rowspan="1" colspan="1">
Binding Action
</td>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Begin SMTP transaction</td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">Receive mail message</td>
</tr>
<tr>
<td rowspan="1" colspan="1"> </td>
<td rowspan="1" colspan="1">End SMTP transaction</td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.start-ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.start-resp</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">MSG.ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-ind</td>
<td rowspan="1" colspan="1"> </td>
</tr>
<tr>
<td rowspan="1" colspan="1">OP.end-resp</td>
<td rowspan="1" colspan="1"> </td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="div3">
<h4><a name="Sec5.1.5"></a>5.1.5 Binding Considerations</h4>
<p>Underlying protocols may provide various levels of functionality
to the binding. It is the responsibility of the binding to
implement a mapping between XML protocol service primitives and
underlying protocol primitives. The mapping should make the best
use of the facilities of the underlying protocol and maximise
efficiency where possible, e.g. connection setup is generally an
expensive operation - bindings for connection oriented protocols
should attempt to minimise the number of connections made for a
given message exchange pattern. In particular, when defining a
mapping the following need to be specified:</p>
<table cellpadding="2" cellspacing="0" width="100%" border="1"
summary="binding considerations">
<colgroup span="2" valign="top"><col width="15%"><col width="85%"></colgroup>
<tr>
<td><b>Protocol</b></td>
<td>
<p>The binding should identify the exact protocol to which XML
protocol is being bound including a version. Examples might be
HTTP/1.1 or SMTP[RFC821]</p>
</td>
</tr>
<tr>
<td><b>Addressing</b></td>
<td>
<p>The binding needs to show how to specify an XML protocol
processor's address with an URL.</p>
</td>
</tr>
<tr>
<td><b>Message Passing</b></td>
<td>
<p>The binding needs to specify unambiguously how to use the
underlying protocol to pass a whole XML Protocol message to a node
specified by a given address. Depending on the underlying protocol
capabilities, the specification may need to detail the
following:</p>
<ol>
<li>
<p>Use of underlying protocol primitives for sending and receiving
messages.</p>
</li>
<li>
<p>Use of underlying protocol headings.</p>
</li>
<li>
<p>Underlying protocol connection management including roles of
initiator and responder, how to handle abnormal terminations, can
responder terminate connection, etc.</p>
</li>
</ol>
</td>
</tr>
<tr>
<td><b>Message Exchange Pattern(s)</b></td>
<td>
<p>The binding needs to specify how underlying protocol sessions
are used in common message exchange patterns including one-way and
request-response.</p>
<span class="ednote"><b>Editorial note </b>[Question: what other
message exchange patterns should we specify here ?]</span>
<p>Here, protocol session means a unit of communication in the
underlying protocol, in HTTP this maps to a single
request/response, in SMTP a session only covers a single act of
sending a message or a single act of receiving a message. In BEEP
the session would possibly map to a channel that would be capable
of many different message exchange patterns.</p>
</td>
</tr>
<tr>
<td><b>Message Ordering Characteristics</b></td>
<td>
<p>The binding needs to specify what message ordering
characteristics the underlying protocol supports. e.g. If two
messages are sent in the same direction in the same session is
their order of arrival guaranteed to be the same as the order in
which they were sent.</p>
</td>
</tr>
<tr>
<td><b>Error Handling</b></td>
<td>
<p>The binding needs to specify how errors in the underlying
protocol will be handled. A non-exhaustive list of things to
consider here is: connection errors, addressing errors, message
transmission errors, abnormal termination.</p>
</td>
</tr>
</table>
<span class="ednote"><b>Editorial note </b>[Question: what other types of error do we
need to consider ?]</span>
</div>
</div>
<div class="div2">
<h3><a name="Sec5.2"></a>5.2 BindingContext</h3>
<p>Each of these underlying protocols supports different features
and capabilities and it is not plausible or desirable to provide a
detailed abstraction that captures the full range of diversity. The
core of XML protocol in respect of the exchange of XML protocol
messages takes a lowest common denominator approach by regarding
the underlying channel as potential lossy and capable of
mis-ordering and duplication. Underlying protocols may offer better
assurances of delivery probability, delivery ordering and at-most
once delivery behaviour.</p>
<p>In the service abstraction provided above, an abstract parameter
known as BindingContext is introduced. The primary purpose of
BindingContext is to act as a collecting 'bucket' for parameters
that control the functionality of the particular set of underlying
protocols available at any given node.</p>
<p>It is expected that the authors of XML Protocol binding
specifications will add structure beneath BindingContext to cover
the features and capabilities of the underlying protocol being
bound. This may also include a descriptor of the ordering, loss and
duplication properties of the underlying protocol, although this
should be treated with caution in multi-hop scenarios.</p>
<p>Some BindingContext extensions may be of more general
applicability than just a single binding. For example, the
references to user ids, private keys and public certificates
necessary for SSL and HTTPS could be shared between both bindings
(were they to exist).</p>
<p>One would therefore expect the structure under BindingContext to
grow along the lines of:</p>
<p class="code">
<code>BindingContext.Shared //A substructure for information shared by several bindings</code>
</p>
<p class="code">
<code>BindingContext.HTTP //A substructure for information related to HTTP</code>
</p>
<p class="code">
<code>BindingContext.SMTP //....</code>
</p>
<p class="code">
<code> </code>
</p>
<p class="code">
<code>....and so on.</code>
</p>
<p>The manipulation of fields within the BindingContext may be
driven from within, for example, an intermediary XML protocol
application on the basis of constructs carried as XML protocol
message blocks within the message being carried.</p>
<span class="ednote"><b>Editorial note </b>Hopefully this captures the general idea behind
BindingContext... the details will evolve over time... indeed they
will evolve as bindings get described.</span>
</div>
<div class="div2">
<h3><a name="Sec5.3"></a>5.3 Attachment of Arbitrary Content</h3>
<span class="ednote"><b>Editorial note </b>This topic is subject to active discussion and
the view presented here is *very* preliminary. There is likely be
considerable diversity of viewpoints that are not captured let
alone resolved here.</span>
<p>Another role of an XML protocol binding is to invoke the
services of underlying protocols and to introduce any mechanism
required to map between the semantics of the underlying protocol
and those of the XML protocol core message delivery
operations XMLP_UnitData. The attachment of arbitrary content
to an XML protocol message is one facet of this mapping.</p>
<p>The core XML protocol messaging services intrinsically handle
arbitrary attachments through the use of the Attachments parameter.
The expectation is that the design of XML protocol WILL specify a
means for encoding arbitrary content and carrying it within an XML
protocol envelope. This mechanism will leverage any pre-existing
work within XML Schema, and will also provide mechanisms for
embedding complete, arbitrary, XML documents within the outer XML
protocol message envelope (itself an XML construct).</p>
<p>Some underlying protocols will support more efficient ways of
carrying arbitrary content and or multiple XML documents. The
normative bindings to an underlying protocol MUST define the
mechanism used by that binding to carry attachments containing
arbitrary content. In the absence of any statement to the contrary
in the definition of a particular protocol binding, the default XML
based encoding for arbitrary content attachments will be taken as
having been specified. Any other scheme specified for a particular
binding must have functional capabilities at least as capable as
the default XML based encoding scheme, in particular it must be
possible to reference the individual attachments from within the
XML protocol message envelope.</p>
</div>
</div>
<div class="div1">
<h2><a name="Sec6"></a>6 References</h2>
<dl>
<dt class="label"><a name="XMLPReqs"></a>XMLPReqs</dt><dd>"XMLProtocol (XMLP) Requirements" (See <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082">http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082</a>.)</dd>
<dt class="label"><a name="SOAP11"></a>SOAP11</dt><dd>SOAP 1.1 Specification (See <a href="http://www.w3.org/TR/SOAP/">http://www.w3.org/TR/SOAP/</a>.)</dd>
<dt class="label"><a name="Issues"></a>Issues</dt><dd>XML Protocol WG Issues List (See <a href="http://www.w3.org/2000/xp/Group/xmlp-issues.html">http://www.w3.org/2000/xp/Group/xmlp-issues.html</a>.)</dd>
</dl>
</div>
<div class="div1">
<h2><a name="Acknowledgements"></a>7 Acknowledgements</h2>
<p>This document is the work of the W3C XML Protocol Working Group.</p>
<p>Members of the Working Group are (at the time of writing, around July 2001, and by
alphabetical order): Yasser al Safadi (Philips Research), Vidur
Apparao (Netscape), Don Box (DevelopMentor), David Burdett
(Commerce One), Charles Campbell (Informix Software), Alex Ceponkus
(Bowstreet), Michael Champion (Software AG), David Clay (Oracle),
Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel
(Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray
Denenberg (Library of Congress), Paul Denning (MITRE Corporation),
Frank DeRose (TIBCO Software, Inc.), Brian Eisenberg (Data
Channel), David Ezell (Hewlett-Packard), James Falek (TIBCO
Software, Inc.), David Fallside (IBM), Chris Ferris (Sun
Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems),
Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich
Greenfield (Library of Congress), Martin Gudgin (Develop Mentor),
Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale
(Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin
Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John
Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co.,
Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu
Software Corporation), Murali Janakiraman (Rogue Wave), Mario
Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins
(Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology
Inc.), Jacek Kopecky (IDOOX s.r.o.), Alan Kropp (Epicentric), Yves
Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner
(AT&T), Richard Martin (Active Data Exchange), Noah Mendelsohn
(Lotus Development), Nilo Mitra (Ericsson Research Canada),
Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Software
Corporation), Mark Needleman (Data Research Associates), Eric
Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft
Corporation), Mark Nottingham (Akamai Technologies), David Orchard
(JamCracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems),
Andreas Riegg (Daimler-Chrysler Research and Technology),
Hervé Ruellan (Canon), Marwan Sabbouh (MITRE Corporation),
Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.),
Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore
(Informix Software), James Tauber (Bowstreet), Lynne Thompson
(Unisys), Patrick Thompson (Rogue Wave), Randy Waldrop
(WebMethods), Ray Whitmer (Netscape), Volker Wiechers (SAP AG),
Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research)
and Dick Brooks (Group 8760).</p>
<p class="prev"> Previous Members were: Eric Fedok (Active Data Exchange) Susan
Yee (Active Data Exchange) Alex Milowski (Lexica), Bill Anderson
(Xerox), Ed Mooney (Sun Microsystems), Mary Holstege (Calico
Commerce), Rekha Nagarajan (Calico Commerce), John Evdemon (XML
Solutions), Kevin Mitchell (XML Solutions), Yan Xu (DataChannel)
Mike Dierken (DataChannel) Julian Kumar (Epicentric) Miles Chaston
(Epicentric) Bjoern Heckel (Epicentric) Dean Moses (Epicentric)
Michael Freeman (Engenia Software) Jim Hughes (Fujitsu Software
Corporation) Francisco Cubera (IBM), Murray Maloney (Commerce One),
Krishna Sankar (Cisco), Steve Hole (MessagingDirect Ltd.) John-Paul
Sicotte (MessagingDirect Ltd.) Vilhelm Rosenqvist (NCR) Lew Shannon
(NCR) Henry Lowe (OMG) Jim Trezzo (Oracle) Peter Lecuyer (Progress
Software) Andrew Eisenberg (Progress Software) David Cleary
(Progress Software) George Scott (Tradia Inc.) Erin Hoffman (Tradia
Inc.) Conleth O'Connell (Vignette) Waqar Sadiq (Vitria Technology
Inc.) Tom Breuel (Xerox) David Webber (XMLGlobal Technologies)
Matthew MacKenzie (XMLGlobal Technologies) and Mark Baker (Sun
Microsystems).
</p>
<p>We also wish to thank all the people who have contributed to
discussions on <a href="mailto:xml-dist-app@w3.org">
xml-dist-app@w3.org</a>.</p>
</div>
</div>
</body></html>