index.html 158 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
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="EN" xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8" /><title>Web Services Internationalization Usage Scenarios</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


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}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
<h1><a name="title" id="title" />Web Services Internationalization Usage Scenarios</h1>
<h2><a name="w3c-doctype" id="w3c-doctype" />W3C Working Group Note 30 July 2004</h2><dl><dt>This version:</dt><dd>
    <a href="http://www.w3.org/TR/2004/NOTE-ws-i18n-scenarios-20040730/">http://www.w3.org/TR/2004/NOTE-ws-i18n-scenarios-20040730</a>
  </dd><dt>Latest version:</dt><dd>
    <a href="http://www.w3.org/TR/ws-i18n-scenarios/">http://www.w3.org/TR/ws-i18n-scenarios</a>
  </dd><dt>Previous version:</dt><dd>
     <a href="http://www.w3.org/TR/2004/WD-ws-i18n-scenarios-20040512/">http://www.w3.org/TR/2004/WD-ws-i18n-scenarios-20040512</a>
  </dd><dt>Editors:</dt><dd>Debasish Banerjee, IBM</dd><dd>Martin J. Dürst, W3C <a href="mailto:duerst@w3.org">&lt;duerst@w3.org&gt;</a></dd><dd>Mike McKenna, University of California</dd><dd>Addison Phillips, webMethods <a href="mailto:aphillips@webmethods.com">&lt;aphillips@webmethods.com&gt;</a></dd><dd>Takao Suzuki, Microsoft <a href="mailto:takaos@belltree.org">&lt;takaos@microsoft.com&gt;</a></dd><dd>Tex Texin, XenCraft</dd><dd>Mary Trumble, IBM</dd><dd>Andrea Vine, Sun Microsystems</dd><dd>Kentaroh Noji, IBM</dd></dl><p>This document is also available in these non-normative formats: <a href="Overview.xml">XML</a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.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" id="abstract" />Abstract</h2><p>This document describes internationalization usage patterns and scenarios 
	  for Web services. It also provides guidance for 
	  implementers of Web service technologies, suggesting methods for 
	  dealing with general international interoperability issues in 
	  services and service descriptions. One goal of this document 
	  is to provide a template for Web service designers to implement 
	  international capabilities in their services.</p></div><div>
<h2><a name="status" id="status" />Status of this Document</h2><p><em>This section describes the status of this document at the time of its
     publication. Other documents may supersede this document. A list of current
	  W3C publications and the latest revision of this technical report can be found
	  in the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
	  at http://www.w3.org/TR/.</em></p><p>This document is a <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#WGNote">W3C Working Group Note</a>, made available by the  of the
     <a href="http://www.w3.org/International/">W3C Internationalization Working Group</a> (<a href="http://www.w3.org/International/ws/">Web Services Internationalization
     Task Force</a>) as part of the <a href="http://www.w3.org/International/Activity">W3C Internationalization Activity</a>. It describes internationalization usage scenarios for Web services and  is intended for review by W3C Members and other
     interested parties. It is also intended to serve as a basis for future work on Web service internationalization.</p><p>The Internationalization Working Group (Web Services Internationalization Task Force)  thinks that this document has reached a sufficient level of maturity to be published as a Working Group Note, and does not intend to issue new versions in the near future. This does not exclude that the document may be updated at a later stage, after more experience  has been gained with the internationalization of Web services.</p><p>The Internationalization Working Group or its successor will keep track of any further comments and discussion relating to this document, and invites any such comments or discussion.  Discussion of this document takes place on the public mailing list 
     <a href="mailto:public-i18n-ws@w3.org">public-i18n-ws@w3.org</a>.
     To contribute, please subscribe by sending mail to 
     <a href="mailto:public-i18n-ws-request@w3.org">public-i18n-ws-request@w3.org</a>
     with <code>subscribe</code> as the subject. The 
     <a href="http://lists.w3.org/Archives/Public/public-i18n-ws/">archive</a> of this list can be read 
     by the general public. Please send comments on this document to the
	  <a href="mailto:www-i18n-comments@w3.org">www-i18n-comments@w3.org</a> mailing list
	  (<a href="http://lists.w3.org/">public archive</a>). Please use [Web Services]
	  or [WSUS] in the subject.</p><p>Publication as a Working Group Note does not imply endorsement by the W3C,
     including the Team and Membership.
</p></div><div class="toc">
<h2><a name="contents" id="contents" />Table of Contents</h2><p class="toc">1 <a href="#IDAASSO">Introduction</a><br />
    1.1 <a href="#IDASSSO">Audience for This Document</a><br />
    1.2 <a href="#IDAYSSO">Scope</a><br />
2 <a href="#IDAOUSO">Introduction to Web Services</a><br />
    2.1 <a href="#IDATUSO">Basic Framework: Anatomy of a Web Service Interaction</a><br />
        2.1.1 <a href="#IDAGVSO">Discovery</a><br />
        2.1.2 <a href="#IDA2VSO">Request</a><br />
        2.1.3 <a href="#IDAVWSO">Response</a><br />
3 <a href="#IDAOXSO">Introduction to Internationalization: Definitions for a Discussion of Web Services</a><br />
    3.1 <a href="#IDARXSO">What are Internationalization and Localization?</a><br />
        3.1.1 <a href="#IDAX0SO">Relationship of Locale to Natural Language</a><br />
        3.1.2 <a href="#S-025">I-025: Specifying and Exchanging International Preferences in Web Services</a><br />
        3.1.3 <a href="#IDA14SO">Locales in Web Service Descriptions</a><br />
        3.1.4 <a href="#IDAP5SO">Locales in SOAP</a><br />
        3.1.5 <a href="#IDAJATO">Faults, Errors, and Human Readable Text</a><br />
    3.2 <a href="#IDAWATO">Locale Independent vs. Locale Dependent Data</a><br />
        3.2.1 <a href="#IDAGBTO">Textual vs. Binary Representations</a><br />
        3.2.2 <a href="#IDAXBTO">Locale-Dependent XML Schema Datatypes</a><br />
        3.2.3 <a href="#IDAFDTO">Examples</a><br />
4 <a href="#IDAXDTO">Basic Web Service Internationalization Scenarios</a><br />
    4.1 <a href="#IDA0DTO">Locale Patterns in Web Services</a><br />
        4.1.1 <a href="#IDAOETO">The Travel Application</a><br />
        4.1.2 <a href="#IDAVETO">Locale Neutral</a><br />
            4.1.2.1 <a href="#IDACFTO">Example: 'GetArrivalTime' Returns Flight Arrival Time</a><br />
        4.1.3 <a href="#IDA2FTO">Client Influenced</a><br />
            4.1.3.1 <a href="#IDAKGTO">Example: 'getItinerary' Get Flight Information in the Requester's Language</a><br />
            4.1.3.2 <a href="#IDAUGTO">Service Description</a><br />
        4.1.4 <a href="#IDA4GTO">Service Determined</a><br />
            4.1.4.1 <a href="#IDANHTO">Example: 'flightCheck' Service</a><br />
        4.1.5 <a href="#IDA5ITO">Data Driven</a><br />
            4.1.5.1 <a href="#IDAMJTO">Example: 'getWeightRestrictions' Gets Flight Luggage Restrictions</a><br />
            4.1.5.2 <a href="#IDARJTO">Example: Stored User Preferences</a><br />
            4.1.5.3 <a href="#IDAWJTO">Example: Data from Service to Service</a><br />
    4.2 <a href="#IDA3JTO">Locale and Language Dependency in Message Exchange Patterns</a><br />
        4.2.1 <a href="#S-009">I-009: One Way Messages</a><br />
        4.2.2 <a href="#S-018">I-018: Data Associated with a Default Attribute</a><br />
        4.2.3 <a href="#I-013">I-013: Conflicts Between Requester's Expectations and Service's Locale</a><br />
    4.3 <a href="#IDAJNTO">Fault Handling</a><br />
        4.3.1 <a href="#S-004">I-004: Producing Fault Reasons in All Available Languages</a><br />
        4.3.2 <a href="#S-005">I-005: Language Matching for Fault Reason Messages</a><br />
        4.3.3 <a href="#S-008">I-008: Locale Sensitive Formatted Data in SOAP Fault Messages</a><br />
    4.4 <a href="#IDARQTO">Legacy Issues</a><br />
        4.4.1 <a href="#pandora">Pandora's box: Using Non-internationalized Data Structures</a><br />
        4.4.2 <a href="#S-019">I-019: Locale Dependent Datatypes</a><br />
        4.4.3 <a href="#IDA1RTO">Existing Web Services</a><br />
    4.5 <a href="#IDACTTO">Character Encodings and Web Services</a><br />
        4.5.1 <a href="#IDAUTTO">SOAP Documents and the MIME Charset Parameter</a><br />
        4.5.2 <a href="#charCodeAttach">Character Encoding of Attachments</a><br />
        4.5.3 <a href="#IDAMUTO">Unsupported Charset in Request Scenario</a><br />
        4.5.4 <a href="#IDAQUTO">Unsupported Charset in Response Scenario</a><br />
        4.5.5 <a href="#IDAVUTO">Unsupported Characters</a><br />
        4.5.6 <a href="#IDA0UTO">Legacy Application Use of Non-Unicode Character Encodings</a><br />
            4.5.6.1 <a href="#IDA5UTO">Calling the Service Requires Transcoding</a><br />
            4.5.6.2 <a href="#IDAFVTO">Service's Internal Implementation Performs Transcoding</a><br />
        4.5.7 <a href="#IDAQVTO">Variability in Transcoding Scenario</a><br />
    4.6 <a href="#IDAZVTO">Passing or Matching International Preferences</a><br />
    4.7 <a href="#IDAGWTO">Intermediaries and Internationalization</a><br />
        4.7.1 <a href="#S-020">I-020: Correlation of Data Between Services in Different Languages</a><br />
        4.7.2 <a href="#I-007">I-007: Interaction of Optional Locale and Language Negotiation and Chained Services</a><br />
        4.7.3 <a href="#S-012">I-012: Caching</a><br />
        4.7.4 <a href="#IDAIXTO">Caching with Locale Information in SOAP Headers</a><br />
    4.8 <a href="#IDANXTO">SOAP Header Structures</a><br />
        4.8.1 <a href="#IDAWXTO">Character Encoding Conversion Scenario</a><br />
    4.9 <a href="#IDADYTO">Service Discovery</a><br />
        4.9.1 <a href="#IDAIYTO">Searching for Web Services Using UDDI</a><br />
        4.9.2 <a href="#I-026">I-026 Searching for Service Descriptions Using My Language</a><br />
        4.9.3 <a href="#IDAU1TO">I-027: Searching for Services Specific to a Region</a><br />
    4.10 <a href="#IDAO2TO">Introspection of Services When Generating WSDL</a><br />
    4.11 <a href="#IDAW2TO">Ordering, Grouping, and Collation</a><br />
    4.12 <a href="#IDAU3TO">Natural Language Text Search</a><br />
        4.12.1 <a href="#IDAY3TO">Language-Neutral Natural Language Text Search</a><br />
            4.12.1.1 <a href="#IDA13TO">Unicode Normalization</a><br />
            4.12.1.2 <a href="#IDAI4TO">Catalog or Index in Multiple Languages</a><br />
        4.12.2 <a href="#IDAV4TO">Language-Specific Natural Language Text Search</a><br />
            4.12.2.1 <a href="#IDAY4TO">Keyword Searching</a><br />
            4.12.2.2 <a href="#IDA24TO">Gender and plural variants</a><br />
            4.12.2.3 <a href="#IDA54TO">Orthographic Variation in Searching ('like' clauses)</a><br />
            4.12.2.4 <a href="#IDAC5TO">Use of Intermediary Translation and Dictionary Look-Up Service</a><br />
            4.12.2.5 <a href="#IDAJ5TO">Phonetic Searches</a><br />
    4.13 <a href="#IDAO5TO">Locale Sensitive Presentation and Human Readable Text</a><br />
        4.13.1 <a href="#S-021">I-021: Data Formatting for End User on Receiver Side</a><br />
        4.13.2 <a href="#S-022">I-022: Data Formatting on Sender Side</a><br />
        4.13.3 <a href="#IDARAUO">Enumerated Values and Object Names</a><br />
            4.13.3.1 <a href="#IDAZCUO">Use of Default English-like Names</a><br />
            4.13.3.2 <a href="#IDAADUO">Types of Names</a><br />
    4.14 <a href="#IDAXDUO">Data Structures</a><br />
        4.14.1 <a href="#IDA0DUO">Times and Time Zones</a><br />
        4.14.2 <a href="#IDAPEUO">Calendars and Dates</a><br />
    4.15 <a href="#IDA1EUO">Legal and Regulatory Goobers</a><br />
        4.15.1 <a href="#IDA4EUO">Modeling Tax, Customs, Legal, and Other Cross-Border and Cultural Considerations</a><br />
    4.16 <a href="#IDAYFUO">Transports</a><br />
        4.16.1 <a href="#IDA3FUO">HTTP</a><br />
        4.16.2 <a href="#IDAGGUO">FTP</a><br />
        4.16.3 <a href="#IDALGUO">SMTP</a><br />
            4.16.3.1 <a href="#IDAPGUO">MIME Tags</a><br />
        4.16.4 <a href="#IDA5GUO">IRIs, URIs, and fun stuff</a><br />
    4.17 <a href="#IDANHUO">Orchestration and Choreography</a><br />
</p>
<h3><a name="appendices" id="appendices" />Appendices</h3><p class="toc">A <a href="#refs">References</a> (Non-Normative)<br />
B <a href="#IDAEOUO">Acknowledgements</a> (Non-Normative)<br />
C <a href="#heisei">Heisei</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="IDAASSO" id="IDAASSO" />1 Introduction</h2><p>This document describes a variety of Web services internationalization
usage scenarios and use cases.</p><p>The goal of the <a href="http://www.w3.org/International/ws/">Internationalization Web Services Task Force</a> is to ensure
that Web services have robust support for global use, including all of the
world's languages and cultures.</p><p>The goal of this document is to examine the different ways that language,
culture, and related issues interact with Web services architecture and
technology. Ultimately this will allow us to develop standards and best
practices for implementing internationalized Web services.
We may also discover latent international considerations in the various Web services standards and propose solutions to the responsible groups working
in these areas.</p><div class="div2">
<h3><a name="IDASSSO" id="IDASSSO" />1.1 Audience for This Document</h3><p>This document addresses several audiences. </p><p>One audience consists of developers of Web services, including the service itself, as well as the Web service description, message exchange pattern, data structures, and discovery. Web service developers need to design services with language or cultural requirements in mind and provide for these options in the data structures and message exchange patterns used by their services.</p><p>Another audience consists of developers of Web service technologies, such as Web service servers ("providers"), directory services, SOAP clients, and the like.  These technologies need to provide support that enables Web service developers to create, deploy, and manage internationalized services. This includes managing multilingual configurations, performing language negotiation, providing suitable infrastructure for obtaining and managing international preferences (such as language or locale), and mapping or transforming data appropriately.</p></div><div class="div2">
<h3><a name="IDAYSSO" id="IDAYSSO" />1.2 Scope</h3><p>The usage scenarios in this document
are generally limited to the following W3C technologies and deliverables:</p><ul><li><p>Web Services Architecture Documents <a href="#WSA">[WSA]</a> <a href="#WSAUS">[WSAUS]</a> <a href="#WSAR">[WSAR]</a> <a href="#WSAG">[WSAG]</a></p></li><li><p>SOAP V1.2 Documents <a href="#SOAP-0">[SOAP-0]</a> <a href="#SOAP-1">[SOAP-1]</a> <a href="#SOAP-2">[SOAP-2]</a> <a href="#SOAP-AF">[SOAP-AF]</a> <a href="#SOAP-EB">[SOAP-EB]</a> </p></li><li><p>WSDL V1.2 Documents  <a href="#WSDL-V20">[WSDL-V20]</a> <a href="#WSDL-B">[WSDL-B]</a></p></li></ul></div></div><div class="div1">
<h2><a name="IDAOUSO" id="IDAOUSO" />2 Introduction to Web Services</h2><p>This section describes the basic infrastructure of Web services necessary to understand
this document. Some definitions of common Web services technology appear in Appendix D.</p><div class="div2">
<h3><a name="IDATUSO" id="IDATUSO" />2.1 Basic Framework: Anatomy of a Web Service Interaction</h3><img src="./WSTF001.jpg" alt="Web services interaction overview, with discovery (top), requester (left), provivder (right), request, and (optional) response" /><p>There are three basic parts to a Web services interaction. The first part is discovery and configuration. The second part is the request. The third part is the optional response. In the diagram above, the purple arrows are the discovery, the blue arrows are the request, and the red arrows are the response.</p><p>It is important to distinguish between the actual <em>service</em> and the Web service <em>provider</em> or <em>agent</em>. The service is the function, method, or other logic that actually is "the service". The provider is the process that receives and emits SOAP messages. In the diagram above, we show the client process and the requester agent as being in a single machine and process, while the provider agent and the actual service are in separate processes. Neither of these is necessarily the case: the provider agent may host the service inside its process, just as the client process and requester agent might be in separate processes or on separate machines.</p><div class="div3">
<h4><a name="IDAGVSO" id="IDAGVSO" />2.1.1 Discovery</h4><p>Discovery of Web services can be done in many ways. For example, the system administrators on either end of the transaction may just discuss their objectives or exchange Web service description files (WSDL). Other options include a UDDI registry or other automated mechanism. </p><p>The Web service description forms the service contract for the service. It contains the information about how to invoke the service and what, if any, response to expect. This information is called the <em>message exchange pattern</em>. The message exchange pattern includes the data structures passed to the service itself and the data structures returned (if any). It may also describe <em>headers</em> that contain the contextual information, either required or optional, that the service may need for features such as quality-of-service, security, transactionality, and so forth. </p><p>Each service or set of services may provide a variety of ways to be invoked, with different URLs, ports, and other information distinguishing the various invocations. Each specific collection (single way of invoking a Web service), consisting of a URL, request and response  is called a <em>binding</em>. </p><p>The Web service description is typically generated by the provider and is subsequently parsed by the <em>requester</em> in order to configure the requester to invoke the service. In some cases the Web service description may also be used to generate the service. </p></div><div class="div3">
<h4><a name="IDA2VSO" id="IDA2VSO" />2.1.2 Request</h4><p>The request goes through several stages:</p><ol class="enumar"><li><p>The caller invokes the service in the requester agent somehow.</p></li><li><p>The requester agent formulates the SOAP message that will invoke the service. It uses the WSDL to create and populate the message body and any headers, attachments, and so forth as set out in the description.</p></li><li><p>The SOAP message is dispatched over the transport (typically HTTP, but not always so) to the URL in the WSDL. This generally represents the provider agent, but may also involve an intermediary server which forwards the request.</p></li><li><p>The provider agent receives and decodes the message. This may result in an error, in which case a SOAP Fault message may be generated as a response.</p></li><li><p>If the SOAP message is decoded successfully, recognized, and valid for a service supported by the provider agent (that is, it was not in error), the provider agent attempts to invoke the service itself.</p><p>Note that invoking the service may result in an error (if, for example, the service isn't currently available) and also that the service itself might result in an error.</p></li></ol></div><div class="div3">
<h4><a name="IDAVWSO" id="IDAVWSO" />2.1.3 Response</h4><p>Not all services generate a response, either when an error is encountered or with a successful result. If the message exchange pattern calls for a response, then the following steps apply:</p><ol class="enumar"><li><p>The service returns its result(s) to the provider agent. This may, as noted above, be a successful result or an error.</p></li><li><p>The provider agent formulates the SOAP message that will be the response. The results of the service are used to build any message body and the provider agent fills in any additional header information. If the service generated an error, then the response message will take the form of a SOAP Fault.</p></li><li><p>The SOAP message is then returned over the transport to the requester agent. Note that from the perspective of the provider agent, this may be an intermediary.</p></li><li><p>The requester agent receives the response and decodes it.</p></li><li><p>The results are passed or made available to the client process.</p></li></ol></div></div></div><div class="div1">
<h2><a name="IDAOXSO" id="IDAOXSO" />3 Introduction to Internationalization: Definitions for a Discussion of Web Services</h2><div class="div2">
<h3><a name="IDARXSO" id="IDARXSO" />3.1 What are Internationalization and Localization?</h3><p>Users from different countries or cultural backgrounds require software and
services that are adapted to correctly process information using their
native languages, writing systems, measurement systems, calendars, and
other linguistic rules and cultural conventions.</p><p>[<a name="international_preferences_termdef" id="international_preferences_termdef" title="International Preferences">Definition</a>: <b>International Preferences</b>]The specification of the particular
set of cultural conventions that software or Web services must employ to
correctly process information exchanged with a user.
</p><p>[<a name="i18n_termdef" id="i18n_termdef" title="internationalization">Definition</a>: <b>Internationalization</b>]The process of designing, creating, and
maintaining software that can serve the needs of users with differing
language, cultural, or geographic requirements and expectations.
</p><p>There are many kinds of international preferences that a Web service may
need to offer, to be considered usable and acceptable by users around the
world. Some of these preferences might include:
</p><ul><li><p>Natural language for text processing: parsing, spell checking, and grammar checking are examples of this</p></li><li><p>User interface language, which may include items like images, colors, sounds, formats, and navigational elements</p></li><li><p>Presentation (human-oriented formatting) of dates, times, numbers, lists, and other values</p></li><li><p>Collation and sorting</p></li><li><p>Alternate calendars, which may include holidays, work rules, weekday/weekend distinctions, the number and organization of months, the numbering of years, and so forth</p></li><li><p>Tax or regulatory regime</p></li><li><p>Currency</p></li><li><p>... and many more</p></li></ul><p>Because there are a large number of preferences, software systems (operating environments and programming languages) often use an identifier based on language and location as a
shorthand indicator for collections of preferences that typify categories of
users. </p><p>HTML for example uses the lang attribute to indicate the language of segments of content. XML
uses the <code>xml:lang</code> attribute for the same purpose. </p><p>Java, POSIX, .NET and other software development
technologies  use a similar-looking (but not identical) construct known as a
<em>locale</em> to activate certain internationalized capabilities in software.</p><p>[<a name="locale" id="locale" title="locale">Definition</a>: <b>Locale</b>] A collection of international preferences, generally related to a geographic region that a (certain category) of users require. These are usually identified by a shorthand identifier or token that is passed from the environment to various processes to get culturally affected behavior.</p><p>Generally, systems that are internationalized can support a wide variety of
languages and behaviors to meet the international preferences of many
kinds of users. When a particular set of content and preferences is operationally
available (often called "enabled"), then the system is referred to as
localized.</p><p>[<a name="localization_termdef" id="localization_termdef" title="Localization">Definition</a>: <b>Localization</b>] The tailoring of a system to the
individual cultural
expectations for a specific target market or group of individuals. The target
group is often indicated by the <a title="locale" href="#locale">locale</a> identifier.
</p><p>Localized systems often need to perform matching between end user preferences represented by the <a title="locale" href="#locale">locale</a> and localized resources. This process is called language (or locale) negotiation.</p><p>[<a name="langnego_def" id="langnego_def" title="language negotiation">Definition</a>: <b>Language Negotiation</b>] The process of matching a user's preferences to available localized resources. The system searches for matching content or logic "falling-back" from more-specific to more-general following a deterministic pattern.</p><p>However, it is important to note that many of the international preferences
do not correlate strongly with <a title="locale" href="#locale">locale</a> identifiers based solely on language and
location.
For example, a system might define a locale of "en-US" (English, United States). This locale encompasses
several time zones, so the user's preferred time zone cannot be deduced
by the locale identifier alone.  Many cultures have more than one way of
collating text, and so the appropriate sort ordering cannot always be 
inferred from the locale. For example, Japanese applications may use different
orderings known as radical-stroke and stroke-radical.
Germany and other parts of the world may use different sort orderings known as
<em>dictionary</em> versus <em>phonebook</em>.
</p><p>Distinguishing these situations requires forethought in the design of the
service
and the setting of reasonable default values.
</p><p>Each user or system in a Web services interaction may have its own
default <a title="locale" href="#locale">locale</a> settings. The interplay between the requester, provider,
service host, intermediaries, and other entities may have complex implications.</p><div class="div3">
<h4><a name="IDAX0SO" id="IDAX0SO" />3.1.1 Relationship of Locale to Natural Language</h4><p>There is not yet an Internet standard for <a title="locale" href="#locale">locale</a> identifiers. However, there is one for natural language identifiers,
<a href="#RFC3066">[RFC3066]</a>.  Since these language identifiers can imply a locale and in the absence of a standard for locale interchange, language identifiers are often used by software as the source for locale identification. Language and locale are distinct properties and should not be used interchangeably, but there is a relationship between these parameters in the area of resource selection and localization. </p><p>The danger of using one for the other lies in the distinction between them. A language preference controls only the language of the textual content, while locale objects are used to control culturally affected (software) behavior within the system.  For example, making the assumption that the language parameter <em>ja</em> (Japanese) means the data should be presented in the locale-determined format for Japan could be a mistake if the requester actually lives and works in Australia.</p><p>The language parameter may be available in several places. In HTTP, there is an Accept-Language header field which can be used (see the HTTP Accept-Language section for more information). MIME has a Content-Language header which contains a language identifier (see the MIME Tags section for more information). In XML, there is an attribute which can be defined for elements called <code>xml:lang</code>. <code>xml:lang</code> marks all the contents and attribute values of the corresponding element as belonging to the language identified. What that means for processing those contents varies from application to application. 
</p><p>Here are some examples:
</p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;p xml:lang="en"&gt;The quick brown fox jumps over the lazy dog.&lt;/p&gt;
&lt;p xml:lang="en-GB"&gt;What colour is it?&lt;/p&gt;
&lt;p xml:lang="en-US"&gt;What color is it?&lt;/p&gt;
&lt;sp who="Faust" desc='leise' xml:lang="de"&gt;
  &lt;l&gt;Habe nun, ach! Philosophie,&lt;/l&gt;

  &lt;l&gt;Juristerei, und Medizin&lt;/l&gt;
  &lt;l&gt;und leider auch Theologie&lt;/l&gt;
  &lt;l&gt;durchaus studiert mit heißem Bemüh'n.&lt;/l&gt;
&lt;/sp&gt;</pre></div></div><p>For more detailed information on the behavior of <code>xml:lang</code>, see the XML specification.</p></div><div class="div3">
<h4><a name="S-025" id="S-025" />3.1.2 I-025: Specifying and Exchanging International Preferences in Web Services</h4><p>Web service and provider implementations, like Web based applications, face the problem of language and <a title="locale" href="#locale">locale</a> negotiation.</p><p>Most Web based application environments have established proprietary standards for performing language and locale negotiation and provide greater or lesser support for managing this form of personalization and content management.</p><p>Web services, in contrast, must allow disparate systems to interoperate in a consistent, non-proprietary manner. This design allows systems to invoke each other without regard to the internal architecture of any part of the system. It is helpful to think of a Web service as an remote procedure call ("RPC"), even though many Web services do not use the SOAP-RPC pattern. Unlike Web applications that can store user preferences in a session-like object hidden from the requester, Web service interoperability requires a shared model, if processing is to produce consistency between expectations and result.</p><p>Some of the problems inherent in dealing with <a title="locale" href="#locale">locale</a> negotiation and identifiers in Web services include:</p><p><em>Web Service Description Scenario A:</em> A method is implemented in the Java programming language which takes a <code>java.util.Locale</code> argument. A Web service description is generated from this method via reflection of the Java class so that the method can be deployed as a Web service. The implementation of the Java <code>java.util.Locale</code> class is exposed in the Web service description and requests must be submitted with field values appropriate for Java, which may be difficult or impossible for non-Java clients to provide.</p><p><em>Description Scenario B:</em> The same method is implemented taking a single string argument instead. The programmer creating the method writes logic to translate the string into the appropriate internal locale object. This logic may be substantial and  must be repeated or shared for each locale-affected method. There is no way to associate the string argument with locale functionality in the provider, locale or language identifiers available in the transport, or to describe the parameter fully and consistently in directories. A system invoking the service might not be able to create a string in the expected format. The provider may not be able to validate the information appropriately.</p><p><em>Description Scenario C:</em> A existing or "legacy" function or method which obtains its locale information from the runtime environment is deployed as a Web service. Existing locale negotiation mechanisms, such as Accept-Language in many application servers, rely on the container (formerly an Application server, but in this case the service provider) to populate this information. The service provider cannot know that this information is needed. The Web service description doesn't have a mechanism for describing this environment setting and the results from the service are limited to the runtime default locale of the provider or service host.</p><p><em>Scenario A, Different Locale Identifiers:</em>  Sender sends a request to a provider and wants a specific
locale and uses its identifier for that. The provider is running on a different platform
and doesn't produce the same result as the sender expects. </p><p id="a-sub1"><em>Scenario A<sub>1</sub>, Different Locale Semantics:</em> Sender sends a request to a provider, expecting a result in a specific
locale-affected format. The provider has a locale with the same ID, but the specific
operation is different from the sender's implementation and the
results don't match. These differences are generally subtle, but may vary widely depending on the specifics of the implementation. For example: collation or formatting dates as a string often display subtle variation from one platform to another.</p><p><em>Scenario A<sub>2</sub>, Fallback Produces Different Results:</em> Sender requests a specific locale. Provider's fallback
produces wildly different results. For example, <code>zh-Hant</code>, the RFC3066 language tag for Chinese written in the Traditional Han script might fall back to <code>zh</code> which represents
generic Chinese and, on many systems, implies the use of the Simplified Han script.</p><p>The following graphics show some Chinese language tags and the resulting locale object in various systems. Note the differences in interpretation:</p><img src="wstf-local1.jpg" alt="International context dialog setting Chinese (zh) in traditional Han (Hant), falling back to a simple zh locale on many systems" /><img src="wstf-local2.jpg" alt="International context dialog setting Chinese (zh) in traditional Han (Hant) for Taiwan (TW), falling back to a zh-TW locale on many systems" /><p>Here are two additional examples, one for Serbian and another for Azerbaijani:</p><img src="./wstf-local3.jpeg" alt="International context dialog setting Serbian (sr) in Cyrillic (Cyrl), producing various fallback locales for different systems" /><img src="./wstf-local4.jpeg" alt="International context dialog setting Azerbaijani (az) in Latin (Latn), producing various fallback locales for different systems" /><p><em>Scenario B:</em> Sender sends a request to a provider, expecting results in in a specific
locale-affected format.  The sender uses its own locale identifiers. The provider and/or service is on an incompatible
platform and cannot interpret the request. For example, converting Microsoft Windows's <code>LCID</code> identifier to Java's <code>java.util.Locale</code>. </p><p><em>Scenario C:</em> Sender wants a specific format or set of processing rules for
a specific item or set of items. The provider is running on a different platform, so the semantics differ. For example, the sender expects the Java <code>SHORT</code> date format, but the provider is written in the C# language.</p><p><em>Scenario D:</em> Sender wants a specific format and sends a picture string or
other very specific identifier. The provider and sender must agree on picture
string semantics. For example, they must agree on what the picture string symbols stand for. Even in the presence of such an agreement, the underlying data in the different locale models may not match, such as the particular abbreviation for a month name.</p><p><em>Scenario E:</em> Sender wants a specific locale and the provider doesn't
support it. This isn't fatal to or detected by the receiving process, which returns data in
an unexpected format or with unexpected results. For example, the date May 6, 2004 might be returned in a locale-formatted string as 06/05/2004 and be interpreted by a U.S. English end user as June 5, 2004.</p><p><em>Scenario F:</em> Scenario E, except that it is detected by or fatal to the service. It may be
difficult to interpret why the service failed. For example, the date returned in Scenario E might have been 13/05/2004, which is clearly in the wrong format for a U.S. user, but the receiving service may not be able to  correct for the problem</p><p><em>Scenario G:</em> Sender requests results that contain human readable text. The provider returns all languages available.</p></div><div class="div3">
<h4><a name="IDA14SO" id="IDA14SO" />3.1.3 Locales in Web Service Descriptions</h4><p>Web service descriptions should consider how to communicate language or
<a title="locale" href="#locale">locale</a> choices in a consistent manner. In the sections that
follow, specific patterns are recommended as good canonical references.
However experience shows that a specific implementation may require additional
contextual information not conveyed with a simple language tag. Generally
this type of additional information should be encoded into the message body (that is, as part of the application's design, not as part of the Web services infrastructure). This expresses specific implementation decisions as part of
the service's signature: you might require additional or different data in future versions. Some of the examples below show this type of information exchanged in headers and some of the complications that may arise from this.</p><p>In the examples below, adoption of a generic method for exchanging
"international contextual information" would allow implementations to
better model the natural language and locale processing choices offered
by the services.</p><p>Implementers should consider adding a language tag to any
operation fault elements to show what language to expect fault messages
to be generated in.</p><p>In all cases, descriptive text should be tagged with its actual content language
using the <code>xml:lang</code> attribute (where permitted). Consideration should be given to
providing documentation within services in alternate languages when the service
is expected to be utilized by users such as those in other countries or who speak
other languages.</p></div><div class="div3">
<h4><a name="IDAP5SO" id="IDAP5SO" />3.1.4 Locales in SOAP</h4><p>Some applications of Web services require a <a title="locale" href="#locale">locale</a> in order to meet end user expectations. An example of this is any process that returns human readable text messages (many more examples exist and some are given below).</p><p>Software developers generally get their messages from language resources using an API provided by the programming environment. This functionality
is implemented in many ways, but the pattern for writing the logic is always similar:
the language and locale preferences are not included in the parameter list of the
service itself because the processing environment (JVM, OS, .NET framework, etc.)
maintains this information as metadata about the process or user. </p><p>A SOAP Processor implementation might provide accessible natural language or locale preference information, received either in the transport (such as HTTP
Accept-Language) or in SOAP headers defined for a particular binding  of a service.</p><p>For example, a .NET SOAP Processor might set the service's thread default
CultureInfo using a language tag. A J2EE implementation might populate
the <code>javax.servlet.ServletRequest</code> class's <code>Locale</code> property with a <code>java.util.Locale</code> constructed from
the ISO639 and ISO3166 fields embedded in a language tag. And so forth.</p></div><div class="div3">
<h4><a name="IDAJATO" id="IDAJATO" />3.1.5 Faults, Errors, and Human Readable Text</h4><p>Fault message "text" elements must be labelled with an appropriate language
identifier, as defined in XML 1.0. That is, an <code>xml:lang</code> tag containing an RFC3066
(or its successor) language identifier. If the transport provides the user's
language preference (such as HTTP Accept-Language), then that language or set
of languages should be preferred, followed by the SOAP Processor machine's
local language preference.</p><p>Ideally there should always be a "message of last resort" included in the fault.
In many cases this message may be in English, but consideration should be given
to the likely users of the system, including the administrators trying to puzzle
out the error. Numeric (or ASCII-only alpha-numeric) error codes should be
considered for inclusion in all fault messages. This may provide valuable
reference when the text of the message itself is in a language not understood
by the recipient.</p><p>When designing specifications intended for interoperability between vendors
or implementations, consideration should be given to enumerating the possible
faults in advance so that reference numbers can be universally and consistently
referenced by disparate implementations.</p></div></div><div class="div2">
<h3><a name="IDAWATO" id="IDAWATO" />3.2 Locale Independent vs. Locale Dependent Data</h3><p>When designing data structures for applications in general  and for 
Web services
   in particular, it is important to design data structures in a 
locale-independent way
   wherever possible. Keeping the data itself from the representation for 
the user leads
   to  a clearer application structure, drastically reduces the number of 
formats for
   interchange, avoids the need for additional information to distinguish 
different
   formats, and allows 'late localization' or 'just in time localization'.</p><p>An interesting, informative paper describing late localization is available here: <a href="#JITXL">[JITXL]</a></p><p> The use of XML Schema in Web services helps promote 
locale-independent data
   because most of the XML Schema datatypes <a href="#XMLS-2">[XMLS-2]</a> have 
been designed
   to be locale-independent.</p><div class="div3">
<h4><a name="IDAGBTO" id="IDAGBTO" />3.2.1 Textual vs. Binary Representations</h4><p>In many traditional applications, the distinction between 
locale-independent and
   locale-dependent datatypes is also a distinction between binary 
 and
   textual representations. </p><p>As an example, a floating-point number is 
represented in some
   binary format internal to an application. It is converted to a textual 
format when displayed to the user, and
   appropriate localization is applied to the formatting. For example, it would use a comma rather 
than a decimal
   point for many European locales.</p><p>Because XML is an
   inherently textual format, the XML Schema Datatypes also are textual. 
Nevertheless,
   most of them were carefully designed to be locale-independent, and are 
intended to
   be used in a locale-independent manner. </p><p>As an example, the XML Schema Datatype 
<code>date</code>
   uses the format <code>YYYY-MM-DD</code> from <a href="#ISO8601">[ISO8601]</a>. This format is similar 
(and in some
   cases even identical)  to some actual formats used in some locales. The format is unambiguous and can be
   understood by a human reading the XML file. Although it is the appropriate format in some locales and not in others, it can be understood to be a locale-independent format. By contrast, if XML Schema had chosen a format 
that is not
   used in any locale, such as just numbering days since a well-defined 
day, it would
   have made the format much more difficult for humans to work with, 
without any
   benefits.</p></div><div class="div3">
<h4><a name="IDAXBTO" id="IDAXBTO" />3.2.2 Locale-Dependent XML Schema Datatypes</h4><p>While most datatypes in XML Schema are locale-independent, there are 
a few  that
   are locale-dependent, and therefore should be avoided. These are 
all the
   datatypes that start with 'g', namely <code>gYearMonth</code>, 
<code>gYear</code>,
   <code>gMonthDay</code>, <code>gDay</code>, and <code>gMonth</code>, and the
   <code>duration</code> datatype.</p><p>The semantics of these datatypes are
   bound to the Gregorian calendar.
   As an example, a field of type <code>gMonth</code> with a value set to <code>5</code> refers to
   the month of May in the Gregorian calendar. This concept cannot be converted to 
calendars that
	do not have their months aligned with the months of the Gregorian
	calendar, such as the Islamic, Hebrew, or Ethiopic calendars. </p><p>As another example, a <code>gMonthDay</code> field with value of <code>09-12</code> refers to September 12<sup>th</sup> in the Gregorian calendar. This date may coincide with the first <em>or</em> the second day of the month <em>Meskerem</em> in the Ethiopian calendar depending on the year.</p><p>On the other hand, the semantics of the other date- and time-related
   XML Schema datatypes are not bound to the Gregorian calendar, although they
   rely on the Gregorian calendar for their lexical form. For example, the
   <code>date</code> <code>2004-09-12</code> can not only be converted to
   <code>September 12, 2004</code> (using the Gregorian calendar), but also
   to the first day in the month Meskerem in the year 1997 in the Ethiopic calendar (the Ethiopic New Year).</p></div><div class="div3">
<h4><a name="IDAFDTO" id="IDAFDTO" />3.2.3 Examples</h4><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAIDTO" id="IDAIDTO" />Example: Some locale-independent XML Schema datatypes</div><div class="exampleInner"><pre>
    TYPE            : EXAMPLE
    ---------------- ---------------------------
    date            : 2003-05-31
    time            : 13:20:00
    dateTime        : 2003-05-31T13:20:00+09:00
    double          : 1267.43233E12
    integer         : 2678967543233</pre></div></div><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAPDTO" id="IDAPDTO" />Example: Locale-dependent XML Schema datatypes</div><div class="exampleInner"><pre>
    TYPE            : EXAMPLE
    ---------------- ---------------------------
    duration        : P1Y2M3D
    gYearMonth      : 2003-05
    gYear           : 2003
    gMonthDay       : 05-25
    gDay            : 25
    gMonth          : 05
</pre></div></div></div></div></div><div class="div1">
<h2><a name="IDAXDTO" id="IDAXDTO" />4 Basic Web Service Internationalization Scenarios</h2><div class="div2">
<h3><a name="IDA0DTO" id="IDA0DTO" />4.1 Locale Patterns in Web Services</h3><p>Distributed processing, as with Web services, must allow for several patterns of
behavior in the service.</p><p>There are four general patterns or policies that may
be applied to the various aspects of a Web service. These four are:
</p><ul><li><p>Locale Neutral</p></li><li><p>Client Influenced</p></li><li><p>Service Determined</p></li><li><p>Data Driven</p></li></ul><div class="div3">
<h4><a name="IDAOETO" id="IDAOETO" />4.1.1 The Travel Application</h4><p>This section uses examples from the travel industry to illustrate all four patterns.</p></div><div class="div3">
<h4><a name="IDAVETO" id="IDAVETO" />4.1.2 Locale Neutral</h4><p>In the <em>Locale Neutral</em> pattern, the service executes in the same
locale-independent way regardless of how it is deployed, invoked or configured. Locale neutral services generally do not provide culturally sensitive processing or deal with human-readable natural language text.</p><p>An example of this would be a service that
returns flight arrival time using the XML Schema datatype xsi:dateTime. This data type is expressed in a universal format.  It is then up to the 
requester to decide if and how to process or format the results.</p><p>This means that the strings embedded in the SOAP message produced from the service's results are intended to be machine readable 
and that data processed by the service does not need to be handled in a culturally sensitive way. The requester might format the value for display to human end user, but this is not part of the service's lifecycle.</p><p>Locale neutral services, being the default, do not generally need to 
announce their locale in their service contracts, although information 
about the locale or language preference of the requester may still be useful to the service or provider (for example in generating fault messages for diagnostic purposes).</p><div class="div4">
<h5><a name="IDACFTO" id="IDACFTO" />4.1.2.1 Example: 'GetArrivalTime' Returns Flight Arrival Time</h5><p>A service to get flight arrival time 'GetArrivalTime', can be written in a locale-neutral way.</p><p>For example, the service response would contain a single value <code>arrivalTime</code> 
using the current UTC (Coordinated Universal Time) time in the ISO 8601<a href="#ISO8601">[ISO8601]</a> 
format: <code>YYYY-MM-DDThh:mm:ss.sss</code>, mandated by the  
<code>time</code> datatype 
in  XML Schema Part 2: Datatypes<a href="#XMLS-2">[XMLS-2]</a>.</p><p>Any requester can transform the result into a local time format, including 
shifting the time into the local time zone.
This way the requester agent, service provider,
the service, and the result are entirely independent of the locale of the 
client, the host,
and the implementer. Hence the service is locale-neutral.</p><p>By contrast, 
a service that returns a locally formatted string containing the arrival date and time should 
be dependent on the locale and language preferences of the requester.</p></div></div><div class="div3">
<h4><a name="IDA2FTO" id="IDA2FTO" />4.1.3 Client Influenced</h4><p>In the <em>Client Influenced</em> pattern, the service provides a specific set 
of localized behaviors which are tailored according to the <a title="locale" href="#locale">locale</a> preferences 
of the requester. </p><p>The service must provide a way for the requester to 
communicate the preferences, and, if there is a response,
it should communicate the actual value used to perform the processing.</p><p>This pattern's name uses the term 'influenced' because the provider and service may not have all possible languages, locales, or sets of preferences available as resources. The service might perform language negotiation and 'fall-back' to a more general set of preferences or use its own preferences if the preferences requested cannot be satisfied.  </p><div class="div4">
<h5><a name="IDAKGTO" id="IDAKGTO" />4.1.3.1 Example: 'getItinerary' Get Flight Information in the Requester's Language</h5><p>Textual information is returned to a requester by a service for display to a human end user. This might include information such as 
fare rules, luggage limitations, etc., that the end user would like in their own language.</p><p>Therefore, the requester sends language preferences information to the provider, which invokes the service. The service looks up and returns the requested textual information in the requested language.</p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;flight&gt;
  &lt;airline&gt;XA&lt;/airline&gt;
  &lt;flight&gt;116&lt;/flight&gt;
  &lt;restrictions xml:lang="en"&gt;Change requires
     USD100.00 fee. Bags limited to two plus one
     carry on.
  &lt;/restrictions&gt;
  &lt;departs&gt;
    &lt;code&gt;SFO&lt;/code&gt;
    &lt;name xml:lang="en"&gt;San Francisco&lt;/name&gt;
    &lt;date&gt;2004-04-15&lt;/date&gt;
    &lt;time&gt;16:45-0800&lt;/time&gt;
  &lt;/departs&gt;
  &lt;arrives&gt;
    &lt;code&gt;AER&lt;/code&gt;
    &lt;name xml:lang="ru"&gt;Сочи&lt;/name&gt;
    &lt;date&gt;2004-04-17&lt;/date&gt;
    &lt;time&gt;23:45+0300&lt;/time&gt;
  &lt;/arrives&gt;
&lt;/flight&gt;</pre></div></div></div><div class="div4">
<h5><a name="IDAUGTO" id="IDAUGTO" />4.1.3.2 Service Description</h5><p>Locale negotiation is required to enable this pattern. The request must 
allow at least one preference and should allow multiple preferences
to be passed, in case the first preference is not available for this service. 
The provider's response
should return the value(s) actually used by the service.</p><p>There are several ways to accomplish this. For example, the service can be written to include this negotiation in its implementation. This requires the service to include the locale preference as an argument in the service's parameter list. </p></div></div><div class="div3">
<h4><a name="IDA4GTO" id="IDA4GTO" />4.1.4 Service Determined</h4><p>In the <em>Service Determined</em> pattern, the service provides a specific localized 
set of behaviors determined prior to the request.</p><p>That is, the service does something in a culturally specific or locale 
affected way and the locale used in this processing is inherent in how the 
service is implemented, installed, deployed, or configured. The major difference between this pattern and the client influenced pattern is that the service and provider do not perform language negotiation for whatever reason.</p><p>For example, the service might use the default 
locale of the system where the provider is running. </p><p>It may also be a 
configuration option of the service, provider, or provider agent. One example 
of this would be a service that provides several bindings, each with a separate 
locale.</p><p>The preferences of the requester therefore do not influence how the service 
executes and may not influence aspects of the service such as the language of 
messages returned and so forth.</p><div class="div4">
<h5><a name="IDANHTO" id="IDANHTO" />4.1.4.1 Example: 'flightCheck' Service</h5><p>A simple example of the service determined pattern could be a service that 
returns the current flight status for particular airport.</p><p>The service takes arguments of <code>xsi:date</code> for the flight date, <code>xsi:string</code> for flight number as input and returns an <code>xsi:string</code> with the current flight status. 
The message returned is in the language where the airport is located.</p><p>A German system, for a flight from Hamburg to Tokyo might include a text 
note, "ein Tag später" to indicate that the flight arrives one day later.</p><p>The service determined pattern may apply to a service for a number of reasons. Some of these include:</p><ul><li><p><em>Implementation Decision.</em> The service's code may be written with a hard-coded locale.</p><div class="exampleInner"><pre>public static void myService(String input) {
   Locale serviceLocale = Locale.GERMANY;
   DateFormat df = DateFormat.getDateInstance(serviceLocale);
   // ...
}</pre></div></li><li><p><em>Service Host Configuration.</em> The service's code may use the system default locale or may not use international APIs that allow the programmer to control the locale.</p><div class="exampleInner"><pre>public static void myService(String input) {
   Locale serviceLocale = Locale.getDefault();
   DateFormat df = DateFormat.getDateInstance(serviceLocale);
   // ...
}</pre></div><div class="exampleInner"><pre>public static void myService(String input) {
   DateFormat df = DateFormat.getDateInstance();
}</pre></div></li><li><p><em>Provider Configuration.</em> The provider or provider host may be configured so that the service's execution environment has a particular locale. In many cases, the provider and the Service Host may be the same thing.</p><div class="exampleInner"><pre>public static void myService(String input) {
   Locale serviceLocale = // call provider specific API to return a locale
   DateFormat df = DateFormat.getDateInstance(serviceLocale);
   // ...
}</pre></div></li><li><p><em>Deployment Decision.</em> The same service might be deployed with different endpoints (URIs) that represent different locales.</p></li></ul><p>The container server could also influence how the service executes 
(if the service's implementation merely reads the default locale 
from the runtime or obtains it from an API).</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAYITO" id="IDAYITO" />Example: Message portions of WSDL for 'flightPrice'</div><div class="exampleInner"><pre>
&lt;wsdl:message name="flightCheck0In"&gt;
&lt;wsdl:part name="arg0" type="xsd:date"/&gt;
&lt;wsdl:part name="arg1" type="xsd:string"/&gt;
&lt;wsdl:part name="arg2" type="xsd:int"/&gt;
&lt;/wsdl:message&gt;

	&lt;wsdl:message name="flightCheck0Out"&gt;
&lt;wsdl:part name="Result0" type="xsd:decimal"/&gt;
&lt;wsdl:part name="Result1" type="xsd:string"/&gt;
&lt;/wsdl:message&gt;
</pre></div></div></div></div><div class="div3">
<h4><a name="IDA5ITO" id="IDA5ITO" />4.1.5 Data Driven</h4><p>In the <em>Data Driven</em> pattern, the service's performance depends on  the locale of the  
data (or, more usually, the data source or back-end system)
itself, rather than the requester, provider or the service itself. </p><p>As an example, a service 
dealing with
flight schedules will use the time zones of the respective departure and 
arrival
locations for departure and arrival times, rather than some server-related 
time zone
or the time zone preference of the client. The ISO 8601 format used by XML Schema might express times using the <a href="#RFC822">[RFC822]</a> UTC offset for each time zone, rather than attempting to use a single time zone in the messages.</p><p>As another example, a service that queries a database might return data sorted or selected based on the database's configuration, rather than an external setting (such as the requester or service locale).</p><div class="div4">
<h5><a name="IDAMJTO" id="IDAMJTO" />4.1.5.1 Example: 'getWeightRestrictions' Gets Flight Luggage Restrictions</h5><p>In this case, the application retrieves information that is dependent on 
the stored flight information.  In the U.S.A. it would be in pounds.  In most other parts of the world it would be in kilograms.</p></div><div class="div4">
<h5><a name="IDARJTO" id="IDARJTO" />4.1.5.2 Example: Stored User Preferences</h5><p>If a user travels to a remote location or uses a different system to access an application than they normally would (by visiting an Internet cafe while on vacation, for example), the local system won't have the user's preferences stored locally.
The user could supply credentials, such as a login, to the application, which uses it to obtain user metadata (such as a language preference stored in an LDAP directory) to control the responses sent to the user.  Thereafter,  text and locale-specific 
information can be formatted on the provider side for inclusion in SOAP messages sent to the requester.  The requester can be 
notified by the provider what the language preferences of the user (or process) 
are, and the requester could then adapt how data is displayed accordingly.</p></div><div class="div4">
<h5><a name="IDAWJTO" id="IDAWJTO" />4.1.5.3 Example: Data from Service to Service</h5><p>This final example is really a permutation of the Service Influenced model, 
but in this case, a Requester "A" requests services from a Provider A, which then 
requests services from Provider "B".  Provider "B" either has a fixed locale, or 
dynamically sets the locale based on information given it by a service 
requester.  That information is then propagated back to the original Requester "A".</p></div></div></div><div class="div2">
<h3><a name="IDA3JTO" id="IDA3JTO" />4.2 Locale and Language Dependency in Message Exchange Patterns</h3><p>When exchanging messages, the requester and the service that the requester
accesses may have different default locales and language preferences. In
addition, there may be more than one service involved in the message
exchange or there may be different clients who consume the
message. Each of these may expect a different locale and language.</p><p>Message exchange between components with different language and/or locales
may result in a failure or unexpected result.  This section describes
various message exchange patterns that need to consider language preferences or that have
potential failure scenarios.</p><div class="div3">
<h4><a name="S-009" id="S-009" />4.2.1 I-009: One Way Messages</h4><p>One-way messages that do not have a response may still have language-related issues.</p><ol class="enumar"><li><p>Service A is defined to receive a message from Requester A and
    deliver to Requester B via Service B. An example of this would be
    similar to a mail server, message queue, or messaging broker triggered by a Web service.</p></li><li><p>Requester A calls Service A.</p></li><li><p>Service B is unable to complete its message transaction and generates
    a fault.</p></li></ol><p>Service B should return a message in a language that matches Requester B's
language preference (so that the administrator of that system can use it).
In addition, if Requester A's preferences are available to Requester B
(that is, Service A got the preferences as part of its input or via an
external mechanism such as the transport), then Requester A's language
preference should be included in the SOAP fault reason text.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAVKTO" id="IDAVKTO" />Example: Message Relaying Fault</div><ul><li><p>Requester A has a language preference of <code>fr-FR</code></p></li><li><p>Provider B is running in an environment with a language preference of <code>de-DE</code></p></li><li><p>Service B is running in an environment with a language preference of <code>en-US</code></p></li></ul><div class="exampleInner"><pre>
  &lt;env:Reason&gt;
      &lt;env:Text xml:lang="fr-FR"&gt;erreur en français&lt;/env:Text&gt;
      &lt;env:Text xml:lang="de-DE"&gt;Verarbeitungsfehler&lt;/env:Text&gt;
      &lt;env:Text xml:lang="en-US"&gt;Processing error&lt;/env:Text&gt;
  &lt;/env:Reason&gt;&gt;
</pre></div></div></div><div class="div3">
<h4><a name="S-018" id="S-018" />4.2.2 I-018: Data Associated with a Default Attribute</h4><p>Default attributes can cause difficulties in Web services, since they often do not travel with their corresponding values. For example, a provider deploys a Web service that returns currency values as a single numeric field, without identifying the currency. For example, the underlying function could assume that all currency amounts are returned using the euro currency, whose ISO 4217 currency code is <code>EUR</code>. Responses from this service are used by multicurrency services; since the default currency type of 'euro' doesn't accompany the numeric values, these other services may make assumptions about which currency applies to those values. This could cause problems with incorrect monetary values going out to requesters.
</p><p>A solution to the above problem is to include the currency value in the message body which corresponds to the numeric value. This solution, however, may not be viable for service providers that are wrapping existing functions or which generate the Web service description via introspection. In these cases, the service provider may need to associate a 'default attribute' with the messages generated by the underlying service. This would allow requesters to recover the currency information.
</p><p>The following example demonstrates multiple currency data transmission in a SOAP message
      and the currency code being provided in a separate element along with the value. A currency data structure such as the one shown below is one suitable solution for internationalized Web services.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAWLTO" id="IDAWLTO" />Example:  Currency Object: Sample Web Service Description</div><div class="exampleInner"><pre>&lt;wsdl:definitions name="currencyExample" targetNamespace="http://www.example.com/wsdl/currencyExample/"&gt;
  &lt;wsdl:types&gt;
    &lt;xsd:schema targetNamespace="http://www.example.com/package/"&gt;
    &lt;xsd:import namespace="http://schemas.xmlsoap.org/soap/encoding/"/&gt;
    &lt;xsd:import namespace="http://www.example.com/something/"/&gt;
        &lt;xsd:complexType name="currencyExample$Price"&gt;
            &lt;xsd:all&gt;
            &lt;xsd:element name="c" minOccurs="0" nillable="true" type="n4:Currency"/&gt;
            &lt;xsd:element name="value" minOccurs="0" nillable="true" type="soapenc:double"/&gt;
            &lt;/xsd:all&gt;
        &lt;/xsd:complexType&gt;
    &lt;/xsd:schema&gt;
    &lt;xsd:schema targetNamespace="http://www.example.com/something/"&gt;
        &lt;xsd:complexType name="Currency"&gt;
            &lt;xsd:all&gt;
            &lt;xsd:element name="currencyCode" minOccurs="0" nillable="true" type="xsd:string"/&gt;
            &lt;/xsd:all&gt;
        &lt;/xsd:complexType&gt;
    &lt;/xsd:schema&gt;
&lt;/wsdl:types&gt;
</pre></div><div class="note"><p class="prefix"><b>Note:</b></p><p>Currency codes are widely standardized using ISO 4217, which provide alpha-3 codes for each currency. The service must, of course, provide validation logic for the currencyCode.</p></div></div><div class="exampleOuter">
<div class="exampleHeader"><a name="IDA1LTO" id="IDA1LTO" />Example: Multiple currencies in a SOAP message</div><div class="exampleInner"><pre>
   &lt;?xml version='1.0' encoding="UTF-8" ?&gt;
  &lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" &gt;
   &lt;env:Header&gt;
   &lt;/env:Header&gt;
   &lt;env:Body&gt;
    &lt;c:purchase&gt;
     &lt;c:apple&gt;
        &lt;price&gt;
		        &lt;currency&gt;
            &lt;currencyCode&gt;USD&lt;/currencyCode&gt;
          &lt;/currency&gt;
          &lt;value&gt;4.56&lt;/value&gt;
        &lt;/price&gt;
     &lt;/c:apple&gt;
     &lt;c:orange&gt;
        &lt;price&gt;
		        &lt;currency&gt;
            &lt;currencyCode&gt;JPY&lt;/currencyCode&gt;
          &lt;/currency&gt;
          &lt;value&gt;442&lt;/value&gt;
        &lt;/price&gt;
     &lt;/c:orange&gt;
     &lt;c:peach&gt;
      &lt;price&gt;
		      &lt;currency&gt;
          &lt;currencyCode&gt;EUR&lt;/currencyCode&gt;
        &lt;/currency&gt;
        &lt;value&gt;3.97&lt;/value&gt;
      &lt;/price&gt;
     &lt;/c:peach&gt;
    &lt;/c:purchase&gt;
   &lt;/env:Body&gt;
  &lt;/env:Envelope&gt;</pre></div></div><p>Adding parameters to the SOAP body requires design changes to the service 
    interface and possibly to the implementation. Adding default values into SOAP headers does not affect the service 
    interface and often can be done statically for a particular resource. This may be an acceptable solution when presenting data from legacy systems through Web services. For example, this could be used for adapting a legacy retail or banking system which conducts all transactions in a single currency to provide data to an international system, however there are many potential issues with this design
	 (see section <a href="#pandora"><b>4.4.1 Pandora's box: Using Non-internationalized Data Structures</b></a>).</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAHMTO" id="IDAHMTO" />Example: Wrapping a non-internationalized service using a default header value:</div><div class="exampleInner"><pre>
   &lt;?xml version='1.0' ?&gt;
   &lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" &gt;
    &lt;env:Header&gt;
     &lt;example:SomeInternationalization xmlns:example="http://example.org/2002/11/21/example"&gt;
      &lt;example:Currency&gt;JPY&lt;/example:Currency&gt;
     &lt;/example:SomeInternationalization&gt;
    &lt;/env:Header&gt;
   &lt;env:Body&gt;
    &lt;c:purchase&gt;
     &lt;c:apple&gt;
      &lt;c:price&gt;123&lt;/c:price&gt;
     &lt;/c:apple&gt;
     &lt;c:orange&gt;
      &lt;c:price&gt;3250&lt;/c:price&gt;
     &lt;/c:orange&gt;
     &lt;c:peach&gt;
      &lt;c:price&gt;3612&lt;/c:price&gt;
     &lt;/c:peach&gt;
     &lt;/c:purchase&gt;
    &lt;/env:Body&gt;
   &lt;/env:Envelope&gt;</pre></div></div></div><div class="div3">
<h4><a name="I-013" id="I-013" />4.2.3 I-013: Conflicts Between Requester's Expectations and Service's Locale</h4><p>In some cases, the locale in which the service provider is executing could affect how parameters sent are evaluated and lead to faults that the requester does not expect or does not understand.</p><ol class="enumar"><li><p>Service A is defined on Provider A, running in a Finnish locale, which queries a company's credit records.</p></li><li><p>Requester A is running in a French locale. The Requester is doing a monthly
audit to verify local customer credit. To request the
credit information from the Finnish provider in manageable chunks, the
requester makes multiple requests in which it requests that the customer records fall into a range.</p><p>If one were to write the query in SQL, it might take the form: <code>SELECT * WHERE (LASTNAME &gt;= low) AND (LASTNAME &lt; high)</code>
iterating over the variables <code>low</code> and <code>high</code>.</p></li><li><p>The first iteration sends a low value of "A" and a high value of "B".</p></li><li><p>Requester A compares the results with its list of customers in that range. The
audit is missing many customer records, since the Finnish provider doesn't
consider names beginning with either "Å" or "Ä" to be less than "B" but the
French requester expects this.</p></li></ol></div></div><div class="div2">
<h3><a name="IDAJNTO" id="IDAJNTO" />4.3 Fault Handling</h3><p>SOAP Version 1.2 allows the provider to send fault messages that provide a description of the <em>reason</em> the service failed in
     multiple languages. SOAP Version 1.2 Part 0: Primer <a href="#SOAP-0">[SOAP-0]</a>
	  explains the &lt;Reason&gt; element as follows:
	  "It must have one or more env:Text sub-elements, each with a unique <code>xml:lang</code> attribute,
      which allows applications to make the fault reason available in multiple languages.
      (Applications could negotiate the language of the fault text using a mechanism built
      using SOAP headers; however this is outside the scope of the SOAP specifications.)"</p><p>This mechanism is suitable
 for returning faults in an environment in which the number of languages is relatively small 
 and the range of languages to be returned is known in advance.</p><p>SOAP implementations are often localized into many languages simultaneously.
To prevent faults from becoming overly large and difficult to manage, implementations 
should include some strategy that reduces the set of languages returned to those of interest to client(s). This requires a mechanism to match the language of the fault as closely as possible to the client's preferences.</p><p>Internationalization best practice is to perform late localization, in which messages are formatted or resolved to strings as late as is reasonable in a process. This preserves language independence and flexibility in responding to multiple users with different language or cultural needs.</p><p>Future versions of SOAP should probably consider allowing additional structured information 
in a Fault so that suitably internationalized clients can perform the localization and 
formatting themselves.</p><div class="div3">
<h4><a name="S-004" id="S-004" />4.3.1 I-004: Producing Fault Reasons in All Available Languages</h4><p>In the absence of language negotiation, the service provider may need to produce
    fault messages in all available languages. </p><p>A service provider detects an error in a request. The provider generates a response containing a SOAP Fault.
In the absence of language negotiation, the
provider must return several, if not all, available languages. The provider cannot know what
languages (resources) are installed, since most programming environments do not
provide functionality that enumerates which languages are actually installed.</p><p>If the service provider wishes to return all languages available, it must request every possible installed locale in turn
in order to poll whether the string is available in that language. Since
resources are often sparsely populated, this suggests significant a processing
overhead to loop over all possible locales, loading resources in turn.</p><p>If the service provider returns a significant portion of the languages available, the size of the Fault message may also be adversely affected.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAIOTO" id="IDAIOTO" />Example: Number of Locales in Selected Operating Environments Default Installation</div><div class="exampleInner"><pre>Solaris 8: 42
Redhat Linux 497
SuSE Linux 9.0: 227
Java JDK 1.4.2: 150
Microsoft .NET: 120</pre></div></div></div><div class="div3">
<h4><a name="S-005" id="S-005" />4.3.2 I-005: Language Matching for Fault Reason Messages</h4><p>The service requester needs to select a matching language from the list of
   fault reasons returned by the service provider. Language tag matching and language ranges are described by RFC3066<a href="#RFC3066">[RFC3066]</a>. Since the <code>xml:lang</code> value associated with the Reason Text element may not be empty, the requester may be unable to  match any of the returned text elements to
its current end user language.</p><p>RFC3066 language tag matching and SOAP Reason Text elements do not provide for a default message: there is only a list of different language messages. So the requester must choose some reasonable default from the list of messages provided.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDA1OTO" id="IDA1OTO" />Example: SOAP fault reason messages in multiple languages</div><div class="exampleInner"><pre>&lt;env:faultReason&gt;
 &lt;env:Text xml:lang="en-US"&gt;Processing error&lt;/env:Text&gt;
 &lt;env:text xml:lang="cs"&gt;Chyba zpracování&lt;/env:Text&gt;
&lt;/env:faultReason&gt;
</pre></div></div><p>If the requester prefers <code>en-GB</code>, then neither string will match
directly for the current requester language preference. Although it
is apparent to a human that <code>en-US</code> is a reasonable match for <code>en-GB</code>, automated
processes are not permitted to make the assumption that languages
with common prefixes are mutually understandable.</p><p>If the requester prefers
<code>ja</code>, then selecting the best fallback is even more difficult, since there is no matching language. How can an implementation choose which message to display?</p></div><div class="div3">
<h4><a name="S-008" id="S-008" />4.3.3 I-008: Locale Sensitive Formatted Data in SOAP Fault Messages</h4><p>A service or service provider substitutes locale-sensitive data into text messages when 
generating fault reasons. </p><p>A service generates a fault during invocation, 
resulting in a SOAP Fault being returned to the requester. In order to properly present values in the Reason element of the Fault, the locale must be known and locale information must be 
available.  For example:</p><ul><li><p>"The date provided, 12 November 2201, was too late."</p></li><li><p>"The argument 12345.678 was too large."</p></li><li><p>"The argument 12345,678- was too small."</p></li></ul><p>The service or provider should format the substitutions in each message according to the 
language and locale of the target audience (typically the requester), which is  not necessarily the same as the locale of the provider 
or service.</p><p>If locale or language preference information is not available from the requester, it may not be possible to generate a message in the user's preferred language. In these cases, the message should follow 
the language preference of the provider or service host.
</p><div class="note"><p class="prefix"><b>Note:</b></p><p>For additional examples of locale-affected formatting in Web services, see
<a href="#S-022"><span>I-022</span></a></p></div></div></div><div class="div2">
<h3><a name="IDARQTO" id="IDARQTO" />4.4 Legacy Issues</h3><p>These scenarios cover internationalization issues that arise when moving existing applications to use Web services.</p><div class="div3">
<h4><a name="pandora" id="pandora" />4.4.1 Pandora's box: Using Non-internationalized Data Structures</h4><p>A data structure may be provided without international considerations.
This may happen, for instance, when a service was originally designed
and targeted for a specific local market and later converted to a
Web service. </p><p>Use and adoption of locale-affected and non-internationalized data structures generally requires a firm understanding of the conventions being adopted and careful implementation. It is generally poor practice in Web services, since the goal of having a Web services infrastructure is usually interoperablity without deep knowledge of the underlying implementation decisions.</p><p>This is an example of a user's daily activity provided in Japanese 12 hour
time scheme.</p><div class="exampleOuter"><div class="exampleInner"><pre>Example: My schedule

Time       : To do
---------- : -----------------------
GOZEN 8:00 : Breakfast
GOGO  0:00 : Lunch
GOGO  7:00 : Dinner
GOZEN 0:00 : Go to bed</pre></div></div><p>GOZEN means "before noon", and generally corresponds to AM. GOGO means
"after noon", and generally corresponds to PM. The problem is GOGO 0:00
is noon rather than 0:00 AM, and GOZEN 0:00 is midnight rather than 0:00
PM.  This is confusing and conversion to an internationally known time
format may fail.</p></div><div class="div3">
<h4><a name="S-019" id="S-019" />4.4.2 I-019: Locale Dependent Datatypes</h4><p>A sender wishes to send locale dependent data to a receiver. The receiver needs to process the locale dependent
   data correctly.</p><p>As an example, if a Japanese sender sends dates to a Japanese receiver, the Japanese 
   sender may wish to send the data in a Japanese date format as required for government records, such as 
   H13-5-31(H stands for the <b> Heisei</b> era; see Appendix <a href="#heisei"><b>C Heisei</b></a>).</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAORTO" id="IDAORTO" />Example: Locale sensitive data in regional datatype</div><div class="exampleInner"><pre>&lt;?xml version='1.0' ?&gt;
   &lt;env:Header&gt;
    &lt;example:WSinternationalization
       xmlns:example="http://example.org/2002/11/21/WS-I18N"&gt;
     &lt;example:dataTypePreference&gt;
      &lt;ja:JDate xmlns:ja="http//example.org/2003/12/3/ja"&gt;EYY-MM-DD&lt;/WS-I18N:JDate&gt;
     &lt;/example:dataTypePreference&gt;
    &lt;/example:WSinternationalization&gt;
   &lt;/env:Header&gt;
   &lt;env:Body&gt;
     ...
     &lt;JDate:birthDate&gt;H13-05-31&lt;/JDate:birthDate&gt;
@@Note: We need to figure out how to properly present this data type
     ...
   &lt;/env:Body&gt;</pre></div></div><p> Wherever possible it is best to avoid locale dependent data types.  Otherwise, the sender and receiver must agree in advance on the data formatting and semantics.</p><p> Many locale- or region-specific data types such as telephone number, address elements, post code, forms of address, etc. can be modeled as strings with patterns.  It is the responsibility of the application on either end to validate, interpret, and format the data properly.</p><p>WSDL and SOAP can be used to constrain locale- or region-specific data fields.</p><p>Applies to: WSDL, SOAP, or Localizable datatype</p></div><div class="div3">
<h4><a name="IDA1RTO" id="IDA1RTO" />4.4.3 Existing Web Services</h4><p>If a Web service is created from a specific agent which is not
internationalized and later the agent is internationalized, then the service
itself may have to be redeployed because the parameter list, headers, or
other information have changed. The developer of the agent is responsible for
supplying the fields, logic, and semantics that will be used to achieve
international capabilities. </p><p>The international considerations in doing this include:</p><ul><li><p>What information is needed to enable international operation.</p></li><li><p>What fields and format are needed to collect that data.</p></li><li><p>Fallbacks, validation and whether the items are optional or not.</p></li></ul><p>If the two versions of the service vary in their approach or don't supply a
suitable mechanism then the service itself may have changed enough....</p><p><em>Scenario A:</em> There is a Service A which is not
internationalized. Some senders start using this service. Later a new version
is created that is internationalized, B. Service B cannot simply replace Service A
because the service signature has changed. Service A must remain deployed until all
users have switched.</p><p><em>Scenario B:</em> There is a Service A which is not
internationalized. Later a new internationalized version, Service B, is created
that is internationalized but which uses the same fields and required values
as Service A. Senders that used Service A may be switched to Service B without warning. Now the
behavior may differ... (users expecting Service A may get different results from what
they expect).</p><p><em>Scenario C:</em> There is a Service A which is not
internationalized. Later a new version is created that adds optional fields
to enable internationalized behavior and this new service is deployed as Service B, replacing Service A.
Existing senders to Service A do not notice the change, but new senders can use the
optional fields to get internationalized results. This may be a way to avoid
the problems with Service B, but may be difficult to maintain over time.</p><p><em>Scenario D:</em> Service B is deployed in place of Service
A. The new service either generates faults (to deprecate the original
invocation) or acts as an intermediary that invokes the original Service A
at some new location. Service B can then record senders that are using the original
service as a way of assisting in migration.</p></div></div><div class="div2">
<h3><a name="IDACTTO" id="IDACTTO" />4.5 Character Encodings and Web Services</h3><p>SOAP interactions rely on being able to exchange data in a consistent,
mutually understandable way. The character encoding of the SOAP message and
the communication of the encoding between senders and receivers enable this
to occur reliably. Because all XML <a href="#XML">[XML]</a> processors must
be able to read entities in both the UTF-8 <a href="#RFC3629">[RFC3629]</a>
and UTF-16 <a href="#RFC2781">[RFC2781]</a> encodings, using UTF-8 or UTF-16
guarantees character encoding interoperability on the SOAP layer. The
Character Model for the World Wide Web <a href="#CHARMOD">[CHARMOD]</a>
document describes these considerations and guidelines.</p><div class="div3">
<h4><a name="IDAUTTO" id="IDAUTTO" />4.5.1 SOAP Documents and the MIME Charset Parameter</h4><p><em>Scenario Definition:</em> A SOAP interaction is based on SOAP 1.1. The documents exchanged use the Content-Type 'text/xml' without a charset parameter. The default character encoding for the 'text/xml' media type is US-ASCII, so omitting the charset parameter may result in failure or data loss. </p><p>The charset
parameter must be supplied in order to ensure correct interoperability.
</p><p>A provider or requester is using SOAP 1.2, which uses
the Content-Type 'application/soap+xml'. If the charset parameter
for that media type is omitted using 'application/soap+xml' then the SOAP
document will be examined for its character encoding using the rules provided in XML. </p><div class="note"><p class="prefix"><b>Note:</b></p><p>In
all cases the charset parameter in the media type takes precedence over that
of the XML that forms the SOAP document. Please refer to RFC3023, XML 1.0,
and RFC2045/2046 for more information.</p></div></div><div class="div3">
<h4><a name="charCodeAttach" id="charCodeAttach" />4.5.2 Character Encoding of Attachments</h4><p>Frequently Web services have attachments.  Since attachments are not part
of the SOAP document, they can be in a different encoding.
In order for an attachment to be processed correctly, the encoding must
be identified for the processing application.</p><p>The SOAP processor (either in the provider, in the case of receiving a SOAP request, or in the requester's client when receiving a response) must handle the attachment correctly. For textual data types, this means providing a correct charset parameter in the MIME type when generating the SOAP message. It also means that the recipient of an attachment must provide this information to the ultimate processor (such as the service or the client). Loss of the encoding may result in corruption of the data or having to guess.</p><p>If the receipt of the attachment and its processing are separated in some manner, it may be important to provide the encoding of the attachment as part of the actual SOAP message type. This way the text can be processed without access to the MIME header information.</p><p>For example, a Web service takes the title of an article and retrieves the full text of the article as an attachment. The database contains articles in many languages and character encodings from sources around the world. The articles are in plain text, with no internal encoding identifier, but when stored in the database, the encoding is inserted as a related parameter. The return SOAP message contains an attribute with the encoding.</p><div class="exampleOuter"><div class="exampleInner"><pre>MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
         start="&lt;article123456@samplerepository.co.uk&gt;"
Content-Description: Sample SOAP envelope with attachment in ISO-8859-15.

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: &lt;article123456@samplerepository.co.uk&gt;

&lt;?xml version="1.0" encoding="UTF-8" ?&gt;
   &lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" &gt;
    &lt;env:Header&gt;
    &lt;/env:Header&gt;
    &lt;env:Body&gt;
      &lt;encExample:articleRetriever&gt;
        &lt;articleTitle xml:lang="fr"&gt;Voici le titre&lt;/articleTitle&gt;
        &lt;articleEncoding&gt;ISO-8859-15&lt;/articleEncoding&gt;
        &lt;articleSize unit="byte"&gt;14355&lt;/articleSize&gt;
      &lt;/encExample:articleRetriever&gt;
&lt;!-- ... --&gt;
     &lt;att:SecondaryPartBag&gt;
	http://samplerepository.co.uk/retrieval/database/article123456
     &lt;/att:SecondaryPartBag&gt;
    &lt;/env:Body&gt;
   &lt;/env:Envelope&gt;

--MIME_boundary
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Content-ID: &lt;article123456@samplerepository.co.uk&gt;

...plain text article in ISO-8859-15...

--MIME_boundary--
</pre></div></div><p>Note that the SOAP message itself is in the UTF-8 encoding, which is different from the attachment's encoding of ISO-8859-15.</p></div><div class="div3">
<h4><a name="IDAMUTO" id="IDAMUTO" />4.5.3 Unsupported Charset in Request Scenario</h4><p> A requester sends a SOAP document in an encoding that the provider  does not support. The provider should
fail and return a fault.</p></div><div class="div3">
<h4><a name="IDAQUTO" id="IDAQUTO" />4.5.4 Unsupported Charset in Response Scenario</h4><p>A requester receives a response. The response is encoded using a character
encoding not supported by the requester. This is an unrecoverable error. Web services providers and requesters should agree
in advance on the collection of encodings that will be used in the
transactions. Ideally all transactions will use a Unicode encoding, such as
UTF-8, since all XML processors are required to handle this encoding.</p></div><div class="div3">
<h4><a name="IDAVUTO" id="IDAVUTO" />4.5.5 Unsupported Characters</h4><p> Some encodings have more characters than are
included in Unicode or use Private Use characters. SOAP messages sent using
these problematic characters may result in transient failure or odd results.
These characters should be avoided wherever possible or some mutually agreed upon private solution should be adopted. Note that this is a rare problem.</p></div><div class="div3">
<h4><a name="IDA0UTO" id="IDA0UTO" />4.5.6 Legacy Application Use of Non-Unicode Character Encodings</h4><p> One use of Web services is to wrap existing or legacy systems. These systems 
may use a legacy (non-Unicode) encoding internally or in their API. Although the 
service provider supports Unicode for sending and receiving SOAP messages, the 
underlying system does not. This may lead to:</p><div class="div4">
<h5><a name="IDA5UTO" id="IDA5UTO" />4.5.6.1 Calling the Service Requires Transcoding</h5><p>The service provider receives and processes a SOAP
message. The processor invokes the service, which uses a
legacy encoding. Data may be lost or corrupted by the transcoding process
between the receiving SOAP processor and the agent. The transaction may seem
to succeed, even though the data is corrupted.</p></div><div class="div4">
<h5><a name="IDAFVTO" id="IDAFVTO" />4.5.6.2 Service's Internal Implementation Performs Transcoding</h5><p> A service may perform transcoding internally, either as a function of its work or due to the use of backend data storage or repositories configured to non-Unicode encodings. The transaction may seem
to succeed, even though the data is corrupted, or it may experience transient errors.</p><div class="exampleOuter"><p>A Web service "insertCustomerRecord" is created for a
relational database. The database uses ISO-8859-1 as its internal encoding. The new record sent by the
requester contains all Japanese characters (which are not supported by the ISO-8859-1 encoding). The invocation of the service succeeds,
even though all of the Japanese characters are converted by the transcoding process to the substitution
character (generally a ?). The failure may not be detectable except by
inspecting the resulting data.</p><p>Additional problems may result. For example, it may be hard to find or remove the resulting data records created by internal transcoding of this nature. In addition, the database may report unexpected key collisions when inserting other records (because portions of both records have been converted to question marks).</p></div></div></div><div class="div3">
<h4><a name="IDAQVTO" id="IDAQVTO" />4.5.7 Variability in Transcoding Scenario</h4><p>Note that the XML Japanese Profile <a href="#XML-JP">[XML-JP]</a>
states that using legacy encodings such as Shift_JIS cannot provide
complete interoperability in information interchange; there are differences
among platforms in the mapping tables they use for this and similar
encodings.</p></div></div><div class="div2">
<h3><a name="IDAZVTO" id="IDAZVTO" />4.6 Passing or Matching International Preferences</h3><p>International preferences, which may include language, locale, collation, time zone and other preferences, may be passed between systems in a variety of ways. Since most of these preferences are not standardized, implementers must define messages or complex types using XML Schema for their specific needs.</p><p>The values available to requesters for the preferences and the matching algorithm in the service (that tries to select the functionality or content based on the values passed) must be set up to deal with fallbacks and suitable defaults.</p><p>Implementers may also have to define internationalized behavior beyond that
described by a mere language or locale choice. It is common for these design decisions to be 
specific to the particular application or particular market being serviced. 
</p><p>An airline flight reservation system might concern itself with details of personalization such as smoking or meal preference, window or aisle seating preference and the like. While these personalization elements are clearly not the realm of a locale or international preference, other items may not be as clearly delineated.</p><p>The same airline reservation system might need to be concerned with local regulations for different airports or with varying time zones.</p><p>The use of a locale or language preference as a short hand for these more complex 
requirements should be carefully considered, and possibly discouraged, in favor of 
making the specific information required for proper operation explicit in the service contract.</p><p>Nonetheless, in some cases the service implementer may wish to use the language or 
locale preference of the end user to determine how the service's processing should proceed.</p></div><div class="div2">
<h3><a name="IDAGWTO" id="IDAGWTO" />4.7 Intermediaries and Internationalization</h3><p>Scenarios in this section deal with issues that arise when services employ intermediaries, such as those discussed in "Service Oriented Architecture
Derivative Patterns Intermediary" (in Web Services Architecture
document<a href="#WSA">[WSA]</a>).</p><img src="./WSTFIntermediary.jpg" alt="An intermediary (in the middle), processing requests from an English, a French, and a Japanese client (to the left), by using an English or a French Web Service (to the right)" /><p>As the diagram indicates, one or more providers offer services. An intermediary
provider can deploy a service that makes requests from these providers and uses the results to satisfy the
requests coming from its clients. The intermediary service may process and/or
integrate the results from different providers to create a new kind of service
or it may simply pass results along. The intermediary service may also cache
either the contents it sends to clients, or the results returned to it by its
providers, for reuse with subsequent requests. In these scenarios it is
important to consider that the providers may return results formulated for
certain international preferences. Clients may also be expecting results
formulated according to their specific requirements. The intermediaries may be expected
to apply appropriate matching between client and provider, or to bridge gaps. 
</p><div class="div3">
<h4><a name="S-020" id="S-020" />4.7.1 I-020: Correlation of Data Between Services in Different Languages</h4><p>Clients requesting from the intermediary service can have different international
preferences.
Therefore the intermediary service must be careful with its algorithms for
determining when to reuse responses that it receives from its providers.
Proper tracking of source data locale and requester locale is required.
Also, correlation and/or aggregation of data may prove difficult if sound
internationalization principles are not used.</p></div><div class="div3">
<h4><a name="I-007" id="I-007" />4.7.2 I-007: Interaction of Optional Locale and Language Negotiation and Chained Services</h4><p>If caching does not take international preferences into account, it is possible
that
cached responses in the wrong language, format, or locale could be returned.
</p><p>Alternatively, in scenario I-020, the intermediary service caches fault reasons
and
other data returned from its providers in each of the languages and cultural
conventions that are requested of it, tracking the locales of each result.
</p><p>Requesters of the intermediary service identify the desired locale of expected
results.
With locale negotiation, the intermediary service can provide results and/or
fault reasons that match the requester's international preferences. </p></div><div class="div3">
<h4><a name="S-012" id="S-012" />4.7.3 I-012: Caching</h4><p>Chained services are a form of intermediary services.
A (source) provider defines a service that has a requirement for a language or
locale preference. Another (intermediary) service provider, defines the same
service
and invokes the first service to utilize its capabilities.
</p><p>The source provider defines an optional header containing a language
request field. If the intermediary service does not also define the optional
header, then when it receives a request it cannot communicate the
requester's preferences to the source provider. The intermediary service
might indicate its own international preference(s) to the source provider or
none, accepting default values. Unless, the description of the
intermediary's service declares its policy on addressing international
preferences, its users may have incorrect expectations of the results.</p></div><div class="div3">
<h4><a name="IDAIXTO" id="IDAIXTO" />4.7.4 Caching with Locale Information in SOAP Headers</h4><p>In a variation of the above scenarios, a SOAP header can be used for locale
negotiation between each layer of requester, intermediary and service.
An example is a Web service wrapper to a legacy client/server application.</p><p>If the intermediary strips off optional headers (either from the requester of its service or the response from its providers), some of the contextual information necessary to interpret the response may be lost.</p></div></div><div class="div2">
<h3><a name="IDANXTO" id="IDANXTO" />4.8 SOAP Header Structures</h3><p>The SOAP header is an optional element which can be used to extend SOAP
processing in an application-specific manner. The header specification
is intentionally minimal so that headers may be tailored to meet the
needs of various applications.</p><p>SOAP headers may be used to initiate or control processing of the message data,
either by the ultimate receiver of the message or by intermediary nodes which
handle the message before it is routed to the ultimate receiver. In this role,
SOAP headers may contain information specifying the routing of SOAP messages
and the processing which may (or must) occur at intermediary nodes. </p><p>Headers may be used to convey additional contextual information about the data in
the body of the SOAP message. In the context of internationalization, although
applications are encouraged to use locale-neutral data formats, processes, and
methodologies, in locale-sensitive scenarios, the SOAP header could be used to
declare the locale to be associated with the SOAP message. Of course, this
technique can be extended to other culture-dependent information that is not
prescribed by the locale. (For example, a SOAP message with shoe size data might
require a SOAP header to declare the shoe measurement system that is used.)</p><p>Of course, generally, it is preferable to include this kind of contextual information
directly with the data. Currency is an example of this: it is preferable to name the monetary unit with the amount. There is a risk when
contextual information is maintained separately from the data (for example by
placing contextual information in a header) that modifications will be made to
one without appropriate changes to the other.</p><p>Another risk is that the message content references data from more than one
locale. This creates a complex header-message relationship which may be difficult to resolve or maintain and suggests that the data formats are ill-conceived.</p><p>The following scenario shows a case in which the message's character encoding is changed (via a header targetted at a specific service in the chain of services). The
SOAP header prescribing the conversion is correctly removed once the conversion
is performed. A variation of this scenario that might represent a problem case would be one
where the header remained after the conversion is performed, incorrectly
prescribing future conversions. It is easy to imagine scenarios where either
the header or the message is modified and the two are no longer properly
coordinated.</p><div class="div3">
<h4><a name="IDAWXTO" id="IDAWXTO" />4.8.1 Character Encoding Conversion Scenario</h4><p>An environment exists in which a legacy application invokes a service.  The receiving service and the legacy requester
are not necessarily using the same character encoding scheme.  An
intermediary site receives the sender's message and, using data in the
message's SOAP header, converts the message's character data to the
encoding of the ultimate receiver, the service.</p><p>A requester sends a SOAP message with an attachment  that uses a character encoding and
character set of its local process.  The ultimate receiver of the
message is a service which can only process UTF-8 encoded data.  An intermediary
provider examines message headers before forwarding the messages to the
service's provider.  If the character encoding is not UTF-8, the
intermediary converts the data, modifies the character encoding
attribute of the message, removes the header, and forwards the message.</p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;?xml version="1.0" encoding="ISO-8859-1" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"&gt;
  &lt;env:Header actor="..."&gt;
    &lt;WS-I18N:convertData
       xmlns:WS-I18N="http://example.org/2002/11/21/WS-I18N"
       env:role="http://www.w3.org/2003/05/soap-envelope/role/next"&gt;
       &lt;WS-I18N:senderEncoding&gt;ISO-8859-1&lt;/WS-I18N:senderEncoding&gt;
    &lt;/WS-I18N:convertData&gt;
  &lt;/env:Header&gt;
  &lt;env:Body&gt;
     . . .[legacy ISO-8859-1 data]
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div><p>SOAP message forwarded from intermediary:</p><div class="exampleInner"><pre>&lt;?xml version="1.0" encoding="UTF-8" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"&gt;
  &lt;env:Body&gt;
     . . .[UTF-8 data]
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre></div></div></div></div><div class="div2">
<h3><a name="IDADYTO" id="IDADYTO" />4.9 Service Discovery</h3><p>Service descriptions are human-readable text intended to describe what the service
does and how it should be used.  To be useful, the description needs to be a natural
language sentence or even a set of keywords in the language that the likely user audience 
will understand. Searching for Web services depends on language or culture. There should be a way to tag the content with the specific language that 
it is in and to allow multiple languages. Otherwise false positives or negatives will result.</p><div class="div3">
<h4><a name="IDAIYTO" id="IDAIYTO" />4.9.1 Searching for Web Services Using UDDI</h4><p>With respect to internationalization, there are four primary scenarios
that will be discussed below:</p><ol class="enumar"><li><p>How do I search for services using  my language to perform the search?</p></li><li><p>How do I search for services that are specific to my region?</p></li><li><p>How do I search for services that can handle my locale or language preference needs?</p></li><li><p>How do I describe a service that handles multiple locales or languages?</p></li></ol></div><div class="div3">
<h4><a name="I-026" id="I-026" />4.9.2 I-026 Searching for Service Descriptions Using My Language</h4><p>I-026.1 Searching for Service Descriptions using my language</p><p>It states in the UDDI Version 3.0.1<a href="#UDDI">[UDDI]</a> specification in the section on <em>Introduction to Internationalization</em>:</p><p>"<em>1.8.4 Use of Multiple Languages and Multiple Scripts</em>

Multinational businesses or businesses involved in international trading at times require the use of possibly several languages or multiple scripts of the same language for describing their business. The UDDI specification supports this requirement through two means, first by specifying the use of XML with its underlying Unicode representation, and second by permitting the use of the <code>xml:lang</code> attribute for various items such as names, addresses, and document descriptions to designate the language in which they are expressed. 
"</p><p>Using <code>xml:lang</code> and multiple entries, a service provider can publish text information about their service in multiple languages.  The name, description, address, and personName UDDI elements may have an associated <code>xml:lang</code> attribute to indicate the language in which their content is expressed.  The policyDescription element contains a description of the effect of the policy implementation.  This element can also have an <code>xml:lang</code> attribute and can appear multiple times to allow for localized versions of the policy description.  Providers are encouraged to do this for target language markets that their service may support.   </p><p>Entity names in UDDI can also provide an Alternate Name in RFC2277 default language, readable in English.  This provides a fallback mechanism to allow a search to identify services even if the named contents may be in a script that is not readable by the entity doing the search.</p><p>The scenario would be as follows:</p><ol class="enumar"><li><p>Service provider publishes service information using UDDI in the provider's default language.  The first entity name in a list is considered to be in the primary name and language.
</p></li><li><p>Service provider, or other entity, adds localized duplicate content to the UDDI entries for the service.</p></li><li><p>Service requester makes a request for service listings, first setting the primary language for searching using the UDDI Subscription API. The language is indicated by setting the <code>xml:lang</code> attribute on query key entities.</p></li><li><p>The UDDI application returns services that match the query in the given
<code>xml:lang</code> language, matching languages according to the language matching 
rules defined in <a href="#RFC3066">[RFC3066]</a>.</p></li></ol><p>Here are some examples from the UDDI Version 3.0.1 specification.

</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAQ0TO" id="IDAQ0TO" />Example: Transliteration</div><p>Transliteration of the primary name of a business (in this case a Chinese flower shop) in Chinese: its alternative name is a transliteration into Latin script (UDDI calls this a 'romanization'):</p><div class="exampleInner"><pre>&lt;businessEntity&gt;
    ...
  &lt;name xml:lang="zh"&gt;黄河花店&lt;/name&gt;
  &lt;name xml:lang="en"&gt;Huang He Hwa Dian&lt;/name&gt;
    ...
&lt;/businessEntity&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAU0TO" id="IDAU0TO" />Example: Translation</div><p>Translation in which the primary name of the business is in Chinese, and is a transliteration of its alternative English name. (UDDI calls this 'transliteration')</p><div class="exampleInner"><pre>&lt;businessEntity&gt;
  ...
  &lt;name xml:lang="zh"&gt;康柏電腦股份有限公司&lt;/name&gt;
  &lt;name xml:lang="en"&gt;Compaq Computer Taiwan Limited&lt;/name&gt;
  ...
&lt;/businessEntity&gt;

</pre></div></div><div class="exampleOuter">
<div class="exampleHeader"><a name="IDAY0TO" id="IDAY0TO" />Example: Multiple Names</div><p>The following shows an example of use of multiple name elements to support a multi-script language and also the use of an acronym.  In the example, the first <em>&lt;name&gt;</em> element is the primary name of the business (a Japanese flower shop) in Japanese Kanji.  The second <em>&lt;name&gt;</em> element is the business' name transliterated into Japanese Katakana.  The third <em>&lt;name&gt;</em> element gives the business' full English name, and the fourth <em>&lt;name&gt;</em> element gives its English acronym. </p><div class="exampleInner"><pre>&lt;businessEntity&gt;
  ...
  &lt;name xml:lang="ja"&gt;日本生花店&lt;/name&gt;
  &lt;name xml:lang="ja"&gt;ニッポンセイカテン&lt;/name&gt;
  &lt;name xml:lang="en"&gt;NIPPON FLOWERS &lt;/name&gt;
  &lt;name xml:lang="en"&gt;NF&lt;/name&gt;
  ...
&lt;/businessEntity&gt;

</pre></div><p>Where multiple name elements are published, the first name element is treated as the primary name, which is the name by which a business would be searched and sorted in the case of multiply-named businesses.  Client applications may use this knowledge to assist in optional rendering of a publisher's primary name or all alternative names.
</p><p>Developers need to know about the organization and provisioning of multiple names, since the first name element is what UDDI searches and sorts on. Developers must provide a mechanism to override the default behavior if the requester is asking for results in a language other than that of the primary entries based on any <code>xml:lang</code> settings in the query structures sent to the UDDI subscription API. </p></div><p>When searching for services, requesters can hunt for names and descriptions by using the UDDI API to pass an optional collection of string values and potentially qualified with <code>xml:lang</code> attributes.  Since "exactMatch" is the default behavior, the value supplied for the name argument must be an exact match.  If the "approximateMatch" findQualifier is used together with an appropriate wildcard character in the name, then any businessService data contained in the specified businessEntity (or across all businesses if the businessKey is omitted or specified as empty) with a matching name value will be returned. Matching occurs using wildcard matching rules. Each name may be marked with an <code>xml:lang</code> adornment.  If  language markup is specified, the search results report a match only on those entries that match both the name value and language criteria. The match on language is a leftmost case-insensitive comparison of the characters supplied. This allows one to find all services whose name begins with an "A" and are expressed in any dialect of French, for example.  Values which can be passed as language criteria are required to obey the rules governing the <code>xml:lang</code> attribute (that is, they must be valid language tags or ranges). </p><p>UDDI does not specify the use of variant find scenarios to allow alternatives such as accent-insensitive matching.  To aid in search retrieval, developers creating a service discovery engine under UDDI may consider alternative match mechanisms.</p></div><div class="div3">
<h4><a name="IDAU1TO" id="IDAU1TO" />4.9.3 I-027: Searching for Services Specific to a Region</h4><p>The UDDI Version 3.0.1 specification states in its introduction to internationalization that UDDI provides features that enable Web service providers to describe the geographical location of different aspects of a business or service, that is, where it offers its products and services, where it is located, or even where it has stores, warehouses, or other branches.  This is done through <em>categoryBags</em> and <em>keyedReferences</em>.</p><p>"The optional categoryBag element allows businessEntity structures to be categorized according to published categorization systems. For example, a businessEntity might contain UNSPSC product and service categorizations that describe its product and service offering and ISO 3166 geographical regions that describe the geographical area where these products and services are offered.

"</p><p>"As within an identifierBag , a keyedReference contains the three attributes <em>tModelKey</em>, <em>keyName</em> and <em>keyValue</em>. The required tModelKey refers to the tModel that represents the categorization system, and the required keyValue contains the actual categorization within this system. The optional keyName can be used to provide a descriptive name of the categorization. Omitted keyNames are treated as empty keyNames. A keyName MUST be provided in a keyedReference if its tModelKey refers to the general_keywords category system.

"</p><p>"For example, in order to categorize a businessEntity as offering goods and services in California, USA, using the corresponding ISO 3166 tModelKey within the UDDI Business Registry, one would add the following keyedReference to the businessEntity's categoryBag:

"</p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;keyedReference
    tModelKey="uddi:ubr.uddi.org:categorization:geo3166-2"
    keyName="California, USA"
    keyValue="US-CA" /&gt;</pre></div></div><p>The use of geographic categorization for services is useful for taxes, import, export, and acknowledgment of available location-specific physical services such as shipping, export, manufacturing, labor, etc.</p><p>The problems involved in identifying the actual geographical or political entity that apply to a service or implementation are not dealt with on the level of ISO 3166 country codes or UDDI directory standards and mechanisms for handling geographic location and applicability of services needs further study.</p></div></div><div class="div2">
<h3><a name="IDAO2TO" id="IDAO2TO" />4.10 Introspection of Services When Generating WSDL</h3><p>Many Web service providers and tools offer the ability to wrap existing code (such as Java Beans or objects, C# methods, or other functions or APIs) with Web services via reflection. Reflection is a process in which software inspects the parameter list and return values of an API call programmatically.</p><p>The process of generating WSDL from an object may involve this kind of reflection. Reflection works well with simple, well-understood types such as integers or strings. It works less well with more complex types.</p><p>Locale affected types are often a source of problems for reflection. For example, the Java Locale object takes three arguments (language, region, and variant)  in its constructor. .NET CultureInfo accepts a slightly modified RFC3066 language identifier. Other locale objects are described by long integers or other values.</p><p>Similarly, dates, calendars, and other locale affected data structures may require specific arguments whose semantics and requirements are not available by introspection. The result may be either that the implementer must hide the implementation details using code in the service itself or rely on the requester to provide appropriate data values.</p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;xsd:complexType name="Locale"&gt;
   &lt;xsd:all&gt;
      &lt;xsd:element name="language" minOccurs="0" nillable="true" type="xsd:string"/&gt;
      &lt;xsd:element name="country" minOccurs="0" nillable="true" type="xsd:string"/&gt;
      &lt;xsd:element name="variant" minOccurs="0" nillable="true" type="xsd:string"/&gt;
      &lt;xsd:element name="hashcode" minOccurs="0" type="xsd:int"/&gt;
   &lt;/xsd:all&gt;
&lt;/xsd:complexType&gt;</pre></div></div></div><div class="div2">
<h3><a name="IDAW2TO" id="IDAW2TO" />4.11 Ordering, Grouping, and Collation</h3><p>The ordering or collation of textual data items is a general concern for internationalized software. The problem is exacerbated when the data can be multilingual in nature. For Web services, in scenarios where the ordering of textual data is critical to its correct utilization, it can be difficult to identify the appropriate collation rules to use with sufficient precision to insure those rules are either followed by any services that operate on the data or that appropriate action is taken to compensate for any services that do not use the desired collation rules (for example, by re-sorting the data downstream).
</p><p>A brief list of these collation issues are described here. An important reference is the  Unicode Collation Algorithm (UCA), described by: <a href="#UTR10">[UTR10]</a>. Although the UCA is a mature standard, it should be noted that there is wide variance in the implementation of collation algorithms; that few of these implementations are based on UCA; and that there is little or no general agreement on identifiers for collation preferences.</p><p>Collation rules cannot be inferred solely from a language identifier or a locale, as the identifiers do not indicate which sort ordering should be used within a locale. A language identifier may be suggestive as to whether a requester expects a particular sort ordering (as with  Traditional or Modern ordering in Spanish, for example) but it may not be definitive.</p><p>Some examples of sort orderings include: telephone, dictionary, phonetic, binary, stroke-radical or radical-stroke. In the latter two cases, the reference (source standard) for stroke count may also need to be cited.
</p><p>Different components or subsystems which are used by a software process may employ different sort orderings. For example, a User Agent may provide a drop-down list which sorts the elements of the list at run-time differently from the other components of the agent. Information retrieved from a database may be ordered by an index which has no correlation to the requester's requirements. When different components or subsystems of a Web Service use different collation rules, then errors can occur. They are not always hard errors (i.e. those that generate faults) but the resulting data, operations, or events, may be incorrect or inconsistent with expectations.</p><p>In the case of services that might use a binary collation (ordering by the code points of text data) there can be differences in ordering introduced by different components using UTF-8 vs. UTF-16 internally.
</p><p>Knowing the language of the requester does not prescribe how sensitive the collation should be. Should text elements that are different by case or accent be treated as distinct? Should certain characters be ignored? For example, hyphens are often ignored so that "e-mail" and "email" sort together.
</p><p>Where case is considered distinct, it may be important to describe whether all lowercase characters precede all uppercase characters, vice versa, or whether they should be intermixed.
</p><p>Often the performance of an application is impacted by collation. For example, if a service returns results in an unknown ordering, the requester may have to sort the results using its local collation rules. This can consume resources and delay the further use of the results until the entire set can be collated. Alternatively, if results are returned in the order needed by the requester, then the requester can begin to process the first records returned without waiting for the remaining records to arrive.
</p><p>Of course, collation can be performed at different stages of data processing and timing can be an important consideration. Database indexes are updated as the data is added to the database, not at the time a request arrives. Requests that can use the preordained collation of the index have a significant performance advantage over requests that either cannot use indexes or must re-sort the results.
</p><p>See <a href="#S-009">I-009</a> and  <a href="#I-013">I-013</a> for a some examples.</p></div><div class="div2">
<h3><a name="IDAU3TO" id="IDAU3TO" />4.12 Natural Language Text Search</h3><p>Invariably, somewhere along the line, an actual human will use a client 
application to look for something.  When that happens, the search process or processes must perform processing on human readable text.  To accommodate 
this, natural language processing is used.   The two primary forms of natural languages processing are 
language-neutral and language-specific.</p><div class="div3">
<h4><a name="IDAY3TO" id="IDAY3TO" />4.12.1 Language-Neutral Natural Language Text Search</h4><p>Most search engines do not understand language, but do understand 
patterns and proximity.  Patterns refer to wildcards and whitespace for 
full-text search.  However, many Asian languages have no concept of 
whitespace in most full text, and therefore may use a scheme where every 
character can be considered to be a word.</p><div class="div4">
<h5><a name="IDA13TO" id="IDA13TO" />4.12.1.1 Unicode Normalization</h5><p>For language neutral applications, text should be normalized to only one 
form (such as base+combining character or all precomposed) according to
Unicode Standard Annex #15 <a href="#UTR15">[UTR15]</a> before 
comparisons are made. For more information, please see <a href="#CharModNorm">[CharModNorm]</a>.</p><p>Note that this kind of normalization is different from and in addition to other forms of normalization such as case-folding.</p></div><div class="div4">
<h5><a name="IDAI4TO" id="IDAI4TO" />4.12.1.2 Catalog or Index in Multiple Languages</h5><p>Catalogs or indexes, if more than one language is to be supported should 
contain language variants of keywords.  This can be populated 
automatically, with translations done semi-automatically, using context 
to aid in creating the right alternate terms. </p><p>This is the ability to have one catalog or index item, with the 
description in many languages.  The service wants to be able to update 
price and quantity in one place per item and have that reflected across 
all languages.   The client wants to search for items in their own 
language. </p><div class="exampleOuter"><p>In the following business XML, a catalog item is defined as follows:</p><div class="exampleInner"><pre>&lt;elementtype name="Product"&gt;
        &lt;model&gt;
            &lt;sequence&gt;
              ...
         &lt;element type="&lt;ShortDescription.html&gt;" occurs="*"/&gt;
         &lt;element type="&lt;LongDescription.html&gt;" occurs="*"/&gt;
              ...</pre></div></div><p>The Descriptions can occur from zero to many times.</p><div class="exampleOuter"><p>The description might be defined as follows:</p><div class="exampleInner"><pre>    &lt;elementtype name="ShortDescription"&gt;
         &lt;model&gt;
                  &lt;string/&gt;
         &lt;/model&gt;
         &lt;attdef name="lang" datatype="xmllang" prefix="xml"&gt;
              &lt;default&gt;en&lt;/default&gt;
         &lt;/attdef&gt;
    &lt;/elementtype&gt;</pre></div></div><p>You should then be able to support the following:</p><div class="exampleInner"><pre> &lt;Product Type="Good" SchemaCategoryRef="C43171803"&gt;
      &lt;ProductID&gt;154723-005&lt;/ProductID&gt;
      &lt;Manufacturer PartnerRef="Acme Tools"&gt;&lt;/Manufacturer&gt;
                       . . .
      &lt;ShortDescription xml:lang="en"&gt;Wrench&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="en_GB"&gt;Spanner&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="da"&gt;fladnoegle&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="es-ES"&gt;llave abierta&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="es-MX"&gt;llave inglesa&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="fr-FR"&gt;clef à fourche&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="de"&gt;Gabelschluessel&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="it"&gt;chiave a forchetta&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="ja"&gt;レンチ&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="ko"&gt;스패너&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="nl"&gt;vorkvormige sleutel&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="pt-PT"&gt;chave fixa&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="pt-BR"&gt;chave de boca&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="zh-CN"&gt;扳子&lt;/ShortDescription&gt;
      &lt;ShortDescription xml:lang="zh-TW"&gt;板鉗&lt;/ShortDescription&gt;
                       . . .
    &lt;/Product&gt;</pre></div></div></div><div class="div3">
<h4><a name="IDAV4TO" id="IDAV4TO" />4.12.2 Language-Specific Natural Language Text Search</h4><p>Most search engines that have any linguistic characteristics are tuned 
to a specific language such as English, German,  or French.  This allows 
techniques, such as stemming and ignoring stop-words to operate 
according to the unique characteristics of the language it is operating 
in.</p><div class="div4">
<h5><a name="IDAY4TO" id="IDAY4TO" />4.12.2.1 Keyword Searching</h5><p>As with language-neutral processing, most search engines don't actually understand the language, but do understand 
patterns and proximity.  Patterns refer to wildcards and whitespace for 
full-text search.  However, many Asian languages have no concept of 
whitespace in full text, and therefore may use a scheme where every 
character can be considered to be a word.</p><p>When searching for keywords,  language must be considered to resolve 
some items such as abbreviations.  For example, in the string, "422 St. Jerome 
St.", "St." could be either "Saint" or "Street". </p></div><div class="div4">
<h5><a name="IDA24TO" id="IDA24TO" />4.12.2.2 Gender and plural variants</h5><p>Some terms have more than one form depending on the gender or 
plurality of the object.  As an example, "Dr. Alvarez" or "Doctor 
Alvarez" in English, could be either "Dr" or "Dra" for "Doctor" or 
"Doctora" in Spanish.  Therefore, to increase the number of valid hits in 
the absence of context, a service should match all variants of a 
matching term if translated to an alternate language.</p></div><div class="div4">
<h5><a name="IDA54TO" id="IDA54TO" />4.12.2.3 Orthographic Variation in Searching ('like' clauses)</h5><p>When operating in a specific language, further normalization may be 
required in addition to abbreviation expansion and character 
normalization.  This is to accommodate variant spellings for the same 
word.  In German, for instance, "Müller" should also return "Mueller"  to 
allow searching across legacy and alternate systems.</p></div><div class="div4">
<h5><a name="IDAC5TO" id="IDAC5TO" />4.12.2.4 Use of Intermediary Translation and Dictionary Look-Up Service</h5><p>To allow a service to provide search services from clients in other 
languages, the service could do the search more than once, depending on 
implementation design.  First in the original text as submitted by the 
client, and in second or subsequent searches after submitting the original query 
to a translation or dictionary look-up service.</p><p>As an example, the address "422 St. Jerome St." could be also be 
represented as:</p><div class="exampleInner"><pre>    en:      422 Saint Jerome Street
    fr:        Rue De 422 Saints Jerome
    es:      Calle De 422 Santos Jerome
    de:      422 Heiliger Jerome Straße
    ja:        聖Jerome通422番地</pre></div><p>The query would look something like this:</p><div class="exampleInner"><pre>Client ==&gt; &lt;query xml:lang="lang0"&gt; ==&gt; service ==&gt; &lt;query xml:lang="lang0".
                                    ^== look-up service
                                    v
                                    ==&gt; &lt;query xml:lang="lang1"&gt;
                                    ==&gt; &lt;query xml:lang="lang2"&gt;
                                    :
                                    ==&gt; &lt;query xml:lang="langN"&gt;</pre></div></div><div class="div4">
<h5><a name="IDAJ5TO" id="IDAJ5TO" />4.12.2.5 Phonetic Searches</h5><p>Note that phonetic searches, such as "Soundex" are usually tuned to 
specific language characteristics.  Soundex, for example, was designed 
for the U.S. Census Bureau in 1890, and first patented in 1918 to allow 
phonetic sorting of English surnames.  It has poor precision, is unable 
to handle multicultural names, produces many false positives and misses 
many potentially correct terms.  That being said, there exist 
proprietary phonological name matching software that produces better 
results across languages and cultures, but it must be tested and 
implemented with the caveat that phonetic searching across languages is 
inherently fraught with errors due to the dialectical differences.</p></div></div></div><div class="div2">
<h3><a name="IDAO5TO" id="IDAO5TO" />4.13 Locale Sensitive Presentation and Human Readable Text</h3><div class="div3">
<h4><a name="S-021" id="S-021" />4.13.1 I-021: Data Formatting for End User on Receiver Side</h4><p>Data is formatted for an end user by the receiver according to the end
   user's preferences and the system conventions. </p><p>The receiver may format data in order to display the data in a user
   interface. Locale sensitive data formatting functions are widely provided by
   internationalization functionality of operating systems, programming
   languages, or applications such as word processors and middleware. Therefore, an
   application may be able to format most locale neutral data using built-in
   internationalization functions. The details of data formatting vary across
   different systems and there may be dependencies on the data provided or on third-party data sources. Therefore, Web services  do not guarantee
   identical presentation of the same data on different systems.</p></div><div class="div3">
<h4><a name="S-022" id="S-022" />4.13.2 I-022: Data Formatting on Sender Side</h4><p>Many applications produce human readable text as output. This makes it necessary for the  service to format  data for viewing by an end user on the receiver side. The service must choose which language message to return and the format of data inserted into the message. The language and locale preferences applied may or may not be the same and these variations could result in human readable messages that are perceived as flawed by the end user.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="IDACAUO" id="IDACAUO" />Example: Populating a  News Feed</div><p>A service is created to populate an RSS news feed with stories from a database. Each of the following examples might be returned for same story:</p><p><em>A.</em> "Theatre Center News: The date of the last version of this document was
2003年3月20日. A copy can be obtained for $5.000,0 or 123.400,57 руб. We would like
to acknowledge contributions by the following authors (in alphabetical
order): Alaa Ghoneim, Behdad Esfahbod, Ahmed Talaat, Eric Mader, Asmus
Freytag, Avery Bishop, and Doug Felt."

</p><p><em>B.</em> "Theater Center News: The date of the last version of this document was
3/20/2003. A copy can be obtained for $5,000.00 or 123,400.57 Russian rubles. We
would like to acknowledge contributions by the following authors (in
alphabetical order): Alaa Ghoneim, Ahmed Talaat, Asmus Freytag, Avery
Bishop, Behdad Esfahbod, Doug Felt, Eric Mader."

</p><p><em>C.</em> "Theatre Centre News: The date of the last version of this document was
20/3/2003. A copy can be obtained for $5,000.00 or 123,400.57 Russian rubles. We
would like to acknowledge contributions by the following authors (in
alphabetical order): Alaa Ghoneim, Ahmed Talaat, Asmus Freytag, Avery
Bishop, Behdad Esfahbod, Doug Felt, Eric Mader."

</p></div><p>Clearly there are many possible (indeed acceptable) variations of the example texts. For example, one
might quibble about the use of first vs. last name sorting in the list,
but clearly the first list was not acceptable English alphabetical order.
If one is quoting a name, like "Theatre Centre News", it might be left
in the source orthography even if it differs from the publication target
orthography. And so on.

However, just as clearly, there limits on what is acceptable English (in this case), and
2003年3月20日, for example, is not.</p></div><div class="div3">
<h4><a name="IDARAUO" id="IDARAUO" />4.13.3 Enumerated Values and Object Names</h4><p>Occiasionally, in the design of an application, there is a need to present
                        enumerated values to an end-user to choose an option for completion of a
                        transaction. Take, for example, an on-line purchase for travel. The credit
                        cards, "MasterCard<sup>®</sup>" and "Visa<sup>®</sup>" have European counterparts known as
                        "Eurocard<sup>®</sup>" and "Carte Bleu<sup>®</sup>" respectively. Each of these go through the
                        same payment clearinghouses and are processed in the same way. It is common
                        to see European payment sites stating that Matercard/Eurocard and
                        Visa/CarteBleu are honored. However, outside of Europe, only the more common
                        global brands are used.</p><p>In this example, a requester includes a user profile in a request for valid payment
                        methods to present to the user. The profile includes the language and country of residence of the user. The service then returns an
                        enumerated list of accepted payment methods. The requester may have no
                        previous knowledge of the payment methods, and so will rely on the service
                        to provide the appropriate types to present to the user. The service will
                        expect one of the values in the enumerated list to be returned as the
                        payment type when completing the transaction.</p><p>From the Open Travel Alliance (OTA), we find the following valid enumeration
                        values for credit cards:</p><p>(From http://www.opentravel.org/2004A/xsd/3/simpletype/PaymentCardCodeType.htm)</p><p>EnumerationDescription</p><ul><li><p>AX   American Express</p></li><li><p>BC   Bank Card</p></li><li><p>BL   Carte Bleu</p></li><li><p>CB   Carte Blanche</p></li><li><p>DN   Diners Club</p></li><li><p>DS   Discover Card</p></li><li><p>EC   Eurocard</p></li><li><p>JC   JCB Credit Card</p></li><li><p>MC   MasterCard</p></li><li><p>TP   Universal Air Travel Card</p></li><li><p>VI   Visa</p></li></ul><p>Each of these would normally be presented in a pull-down pick list, but a
                        particular organization may wish to discard with the differences, and
                        present the list in Europe as:</p><div class="exampleOuter"><div class="exampleInner"><pre>
...
VI  Visa/Carte Bleu
MC  Eurocard/MasterCard 
...</pre></div></div><p>and in North America as:</p><div class="exampleOuter"><div class="exampleInner"><pre> 
... 
MC  MasterCard 
VI  Visa 
...</pre></div></div><div class="div4">
<h5><a name="IDAZCUO" id="IDAZCUO" />4.13.3.1 Use of Default English-like Names</h5><p>In an enumerated list, best practices dictate that there is an internal value
                        from which actions are determined, and an external value, which is presented
                        to an end user. In the same way, even if a service has been told what locale
                        a requester is using, the service may want to provide alternate default
                        display values that can be used for debugging purposes or bilingual status
                        or transaction displays. </p></div><div class="div4">
<h5><a name="IDAADUO" id="IDAADUO" />4.13.3.2 Types of Names</h5><p>Names in an enumerated list fall into three primary categories, each used
                            for different purpose. </p><p>Display names are those which are presented to the user. A well designed
                            system will have only the Requester generating and displaying these
                            values. If necessary, a Requester should be able to request a set of
                            standard localized names from a Service. Those names should be keyed to
                            culture-neutral values that are used for communication between processes.</p><p>(from http://www.opentravel.org/2004A/xsd/9/complextype/SeatingPrefType.htm)</p><p>Since credit card names are trademarked and don't change much from one language to another, the example below will use seat selection for "Aisle", "Center", "Window" as an example.</p><p>The OTA Schema, for instance, passes strings for this value, but an
                            end-user will want to see the values in their own language. In German,
                            the choices would be Gang, Mitte, and Fenster.  
                            Therefore, the designer of the Service may wish to return qualified locale sensitive display names that 
                            the Requester can use for display to the end user.  This is especially useful for instances 
                            where terminology or messages might change and it is not desired to update the whole
                            requester application just to update a few terms.
                        </p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;xs:attribute  name="SeatPosition"  type="xs:string"  use="optional"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation  xml:lang="en"&gt;Preferred position of seat in a row, 
        such as Aisle, Center, Window, etc.&lt;⁄xs:documentation&gt;
    &lt;⁄xs:annotation&gt;
    &lt;xs:simpleType&gt;
        &lt;xs:restriction base="StringLength16"&gt;
            &lt;xs:enumeration value="Aisle"&gt;
                &lt;displayName xml:lang="en"&gt;Aisle&lt;⁄display&gt;
                &lt;displayName xml:lang="de"&gt;Gang&lt;⁄display&gt;
            &lt;⁄xs:enumeration&gt;
            &lt;xs:enumeration value="Center"&gt;
                &lt;displayName xml:lang="en"&gt;Center&lt;⁄display&gt;
                &lt;displayName xml:lang="de"&gt;Mitte&lt;⁄display&gt;
            &lt;⁄xs:enumeration&gt;
            &lt;xs:enumeration value="Window"&gt;
                &lt;displayName xml:lang="en"&gt;Window&lt;⁄display&gt;
                &lt;displayName xml:lang="de"&gt;Fenster&lt;⁄display&gt;
            &lt;⁄xs:enumeration&gt;
        &lt;⁄xs:restriction&gt;
    &lt;⁄xs:simpleType&gt;
&lt;⁄xs:attribute&gt; 
</pre></div></div><p>The actual enumeration value, not the displayName, would be used internally and passed from
                            Requester to Service, while the displayName would be presented to the
                            user interface according to locale.</p></div></div></div><div class="div2">
<h3><a name="IDAXDUO" id="IDAXDUO" />4.14 Data Structures</h3><div class="div3">
<h4><a name="IDA0DUO" id="IDA0DUO" />4.14.1 Times and Time Zones</h4><p>Date and time handling in Web services is affected by time zones.  However, there 
is no standard parameter to indicate the time zone alone.  Locales are not useful for 
determining time zone because there can be many time zones within a given locale. Applications' needs with regard to time zone also differ.</p><p>For example, for a single timestamp the RFC 3339 UTC offset is sufficient. For processing dates (such as calculating a duration) you may need more information (such as daylight savings or summer time rules, if they apply).</p><p><em>Scenario A:</em>  A Web service returns the current time of a city listed as part of 
the request.  The requester sends the name of a city (with an <code>xml:lang</code> attribute value) and 
the provider returns the current time in that city formatted in <a href="#ISO8601">[ISO8601]</a> format 
(hh:mm:ss).</p><p><em>Scenario B:</em>  A Web service takes a date/time value in ISO 8601 format 
(yyyymmddThhmm+hhmm) and the name of a city with an <code>xml:lang</code> attribute value, and returns 
the value converted to the specified city's time zone.</p><p><em>Scenario C:</em>  As a sub-process of a "meeting manager" service, a Web service inspects 
multiple appointment books looking for mutually available time slots.  The requester 
provides a span of time in ISO 8601 format (yyyymmddThhmm+hhmm) using a start 
time and an end time.  The inspected appointment books store information about their 
time zones.  The service returns a series of time spans in the ISO 8601 format.</p></div><div class="div3">
<h4><a name="IDAPEUO" id="IDAPEUO" />4.14.2 Calendars and Dates</h4><p>A Web service is set up to calculate a calendar date and send it back to
the requester.  The value returned represents a specific date on the calendar, 
not a timestamp value as might be associated with a particular locale or
time zone.  The service may need to take in information such as the calendar 
type, year, and related descriptive information.

</p><p>Scenario A:  A service calculates the date for Easter, Passover, or Ramadan for 
any given year, returning a date value in ISO 8601 format. These religious holidays are partly based
on astronomical events, such as lunar phases, as well as historical tables.
They are not strictly calendar dependent in the way that many secular holidays,
such as various national independence days or leader's birthdays are, nor are 
they predictable, for example, the fourth Thursday in November. Thus the need 
for a service to calculate the date might be necessary.  The
SOAP request would contain a holiday and a year in ISO 8601 format.  In 
addition, some other data may be required, such as for Easter there may be a 
parameter specifying "Orthodox" or "Western".  The Web service would in turn 
calculate the appropriate date and send a message back to the requester with the
calculated date.  Some other service may be used to convert the returned date 
value into a specified calendar type, such as the Japanese calendar.

</p><p>Scenario B:  A service calculates historical dates in different parts of
the world and returns an equivalent ISO 8601 date to the
requester.  The SOAP request would contain a date and its country of
origin.  For example, a request might have the date <code>1812-08-26</code> and the
origin "Russia".  Russia was using a different calendar from places such as
Italy or France at that time; what would appear as the same date was actually 
several days different.  While this may look like it is part of the locale due to
the country of origin, it should not be treated as such.  Locales are
typically associated with the end user, not with a piece of data, and a
locale does not contain information on historical times.

</p><p>Scenario C:  A service calculates Chinese New Year for any non-Chinese
calendar type.  The SOAP request would include a parameter with the
calendar type, such as "Gregorian", "Hebrew", or "Japanese Imperial".
The locale is irrelevant to the calculation, since the
requester may be looking for information unrelated to user preferences
or system settings.</p></div></div><div class="div2">
<h3><a name="IDA1EUO" id="IDA1EUO" />4.15 Legal and Regulatory Goobers</h3><div class="div3">
<h4><a name="IDA4EUO" id="IDA4EUO" />4.15.1 Modeling Tax, Customs, Legal, and Other Cross-Border and Cultural Considerations</h4><p>Tax, customs, legal, and similar matters are usually country-specific.  However, 
much of the types of processing involved are the same.  For example, many tax 
calculations take a percentage or set of percentages of a given amount.  A set 
of Web services can work together to provide information for many countries, 
avoiding code and process duplication.
</p><p>There is more information needed in these types of processes than just the 
country identifier.  Language information is crucial for legal documents, and 
important for other regime-type operations as well.  For tax calculations, the 
currency of the incoming values as well as the currency of the result must be 
specified.  Other cross-border services will likely require other types of 
information, such as address formats or some sort of legal status indicator. </p><p><em>Scenario A:</em>  Service A, specific to Country C, takes in the value of a 
sale, a language parameter, and the names of the city and the province.  The 
currency is limited to Country C's official currency.  Service A then calls a 
set of services, translating names into identifiers.  Service B takes in a city 
id and a monetary value, then calculates city sales tax based on current tax 
tables it retrieves from other services; it returns the tax amount as a numeric 
value.  Service C performs a similar function for taxes at the provincial level. 
</p><p>Service A then takes those monetary values and returns them with identifying 
tags for the city and provincial tax.</p><p>If Service A were to be used for multiple countries, there would have to be 
additional parameters, for example:
</p><ul><li><p>a country identifier</p></li><li><p>other regional identifiers, such as county, state, province, or region</p></li><li><p>a currency identifier</p></li></ul><p>There would have to be a function to handle currency calculations, possibly in a 
separate service.  The additional tax regions need to be managed, again by 
separate services.</p><p><em>Scenario B:</em>  An application uses a Web service to send DVDs to rental customers 
around the world. DVDs contain a region code that limits where they can be 
played (according to the country they are intended for.) The Web service takes 
the country ID of of the customer and selects the right region code DVD to send.</p><p><em>Scenario C:</em>  A service takes a country ID, looks it up in a database, and 
return the driving rules for that country.</p><p>Configuration or business logic may have to be carefully designed in order to deal with these kinds of issues.</p></div></div><div class="div2">
<h3><a name="IDAYFUO" id="IDAYFUO" />4.16 Transports</h3><p>Web services may use a variety of transport technologies and protocols.  Many of 
these have parameters defined for data identification.  Some of these parameters are 
necessary for proper processing of international data.  The specifics of several 
transport protocols are discussed in this section.</p><p>Note that each transport has different capabilities regarding internationalization-related metadata and that the transport stack that processes this metadata and the service provider may not be the same process. Although transports can sometimes pass interesting data about the requester, this doesn't fit well with the general Web services design of using XML data structures in a composable way: the metadata can get lost too easily and doesn't reflect the needs of the service provider accurately.</p><div class="div3">
<h4><a name="IDA3FUO" id="IDA3FUO" />4.16.1 HTTP</h4><p>The HyperText Transport Protocol (HTTP) is often used for Web service message 
transport.  HTTP contains some header fields which are useful for identifying 
sender preferences and capabilities.  One of these fields of interest when internationalizing a service is Accept-Language.

</p><p>Accept-Language takes one or more language identifiers in RFC3066 (or its 
successor) format as its parameters.  Each language identifier can have a 
quality value which gives a relative priority.  Here is an example:

</p><div class="exampleInner"><pre>Accept-Language: zh-cn, fr-ch;q=0.8, fr;q=0.7</pre></div><p>The above could be read as "Simplified Chinese is preferred, but Swiss French is 
acceptable, as are other types of French."  There is more information about the 
handling of Accept-Language in the HTTP 1.1 specification.</p><p>A Web service requester using HTTP can include an Accept-Language field to 
indicate the languages preferred.  The provider could then take that information 
and use it to return human-readable data in the appropriate language.</p><p>Some Web application environments, such as .NET or J2EE, use this field to try and determine the user locale for use in application logic. As noted above, while this might be an acceptable short term strategy for some implementations, the design doesn't fit with the distributed nature of Web services. At best, a Web service provider can merely infer some information about the requester or the requester's host from this field and this may not be sufficient to provide a high quality of service.</p></div><div class="div3">
<h4><a name="IDAGGUO" id="IDAGGUO" />4.16.2 FTP</h4><p>File Transfer Protocol (FTP) is a simple transport mechanism that can be used 
to transport Web service documents.  The main international consideration in using FTP is 
to specify the representation type as I (Image), allowing 8-bit values to pass 
unchanged through the transfer.</p><p>File names, path names, and character encoding issues may intrude here, since the FTP specification provides limited guidance.</p></div><div class="div3">
<h4><a name="IDALGUO" id="IDALGUO" />4.16.3 SMTP</h4><p>Simple Mail Transfer Protocol (SMTP) has no particular provisions for
international data.  SMTP itself is limited to 7-bit data, but can transport
8-bit data.  Its main restriction is an 8-bit gateway; that is, encodings such
as UTF-16 and UTF-32 may not be successfully transmitted and should be avoided.</p><div class="div4">
<h5><a name="IDAPGUO" id="IDAPGUO" />4.16.3.1 MIME Tags</h5><p>Multipurpose Internet Mail Extensions (MIME) tags are necessary for a multipart
SOAP request, for example, when transmitting the SOAP message itself or a SOAP attachment.  MIME contains a
number of headers which may be used for international data.</p><p>MIME can identify the character encoding of attachments (via the Content-Type charset attribute). This is useful when the attachment does not
identify is own charset internally.  Examples of such attachments
are plain text documents which cannot contain markup identifying the character encoding and legacy markup
documents which do not contain a charset tag by omission.  If the attachment
contains an internal charset tag, the MIME charset parameter should be omitted
to avoid an inadvertent mismatch.</p><p>MIME can also contain a Content-Language tag.  While it is better to indicate
the document language inside the document itself, sometimes it isn't possible.
For example, if there is an image attachment which contains embedded text, the
Content-Language header can identify the language externally.</p><p>Interpreting MIME Content-Language headers as a locale is problematic.
Although the HTTP transport's Accept-Language header is sometimes use for
this purpose, Content-Language generally indicates the actual language
of the content.</p><p>See the example in <a href="#charCodeAttach"><b>4.5.2 Character Encoding of Attachments</b></a>.</p></div></div><div class="div3">
<h4><a name="IDA5GUO" id="IDA5GUO" />4.16.4 IRIs, URIs, and fun stuff</h4><p>Internationalized Resource Identifiers (IRIs, see <a href="#IRI">[IRI]</a>)
  should be used wherever URIs would be used, to allow the use of non-ASCII
  characters in a natural way. This can be done automatically by using the
  anyURI data type from XML Schema <a href="#XMLS-2">[XMLS-2]</a>.</p></div></div><div class="div2">
<h3><a name="IDANHUO" id="IDANHUO" />4.17 Orchestration and Choreography</h3><p>Orchestration of Web services involves the creation of a sequence of services, 
generally wrapped as a single process or thread of execution.</p><p>Choreography is a higher-level form of orchestration, generally involving orchestration of Web services that span multiple servers or systems.  </p><p>Orchestration and choreography include many of the 
attributes of traditional business processes, such as transactionality, security, 
reliability, and so forth. They may involve the interaction between Web services, applications, and human interactive workflow processes.</p><p>In many cases orchestrated or choreographed sets of services may be wrapped so that they appear as a single service that itself can be invoked.</p><p>The locale patterns, policies, and their interactions  previously discussed in this document apply to 
the results of orchestrated collections of Web services, as well as to the individual services that make up the orchestrated service. In fact, the locale patterns may form part of the business logic or 
influence the execution, selection of service targets, and other operational or 
runtime attributes of an orchestration.</p></div></div></div><div class="back"><div class="div1">
<h2><a name="refs" id="refs" />A References (Non-Normative)</h2><dl><dt class="label"><a name="CHARMOD" id="CHARMOD" />[CHARMOD]</dt><dd>
"Character Model for the World Wide Web 1.0: Fundamentals",
Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin,
W3C Working Draft 25 February 2004.  (See http://www.w3.org/TR/2004/WD-charmod-20040225/.)</dd><dt class="label"><a name="CharModNorm" id="CharModNorm" />[CharModNorm]</dt><dd>"Character Model for the World Wide Web 1.0:
Normalization", Martin Dürst, François Yergeau, Richard Ishida, Misha Wolf,
Tex Texin, Addison Phillips, W3C Working Draft 25 February 2004.  (See http://www.w3.org/TR/2004/WD-charmod-norm-20040225/.)</dd><dt class="label"><a name="IRI" id="IRI" />[IRI]</dt><dd>"Internationalized Resource Identifiers (IRIs)",
Martin Dürst and Michel Suignard, Internet Draft draft-duerst-iri-09.txt
(work in progress, see http://www.w3.org/International/iri-edit/), 19 July 2004.  (See http://www.w3.org/International/iri-edit/draft-duerst-iri-08.txt.)</dd><dt class="label"><a name="ISO8601" id="ISO8601" />[ISO8601]</dt><dd>"Representations of dates and times", ISO (International
Organization for Standardization), 1988-06-15.  (See http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780&amp;ICS1=1&amp;ICS2=140&amp;ICS3=30.)</dd><dt class="label"><a name="JITXL" id="JITXL" />[JITXL]</dt><dd>"JIT Localization", Mark Davis, IBM, 21 March 2003  (See http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/jit_localization.html.)</dd><dt class="label"><a name="RFC822" id="RFC822" />[RFC822]</dt><dd>"Standard for the Format of ARPA Internet Messages",
Revised by David H Crocker, 13 August 1982.  (See http://www.ietf.org/rfc/rfc822.txt.)</dd><dt class="label"><a name="RFC2277" id="RFC2277" />[RFC2277]</dt><dd>IETF Policy on Character Sets and Languages, Harald Alvestrand,
RFC 2277, January 1998.  (See http://www.ietf.org/rfc/rfc2277.txt.)</dd><dt class="label"><a name="RFC2616" id="RFC2616" />[RFC2616]</dt><dd>
"Hypertext Transfer Protocol -- HTTP/1.1",  R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, RFC 2616, June 1999.  (See http://www.ietf.org/rfc/rfc2616.txt.)</dd><dt class="label"><a name="RFC2781" id="RFC2781" />[RFC2781]</dt><dd>UTF-16, an encoding of ISO 10646,
P. Hoffman, F. Yergeau. RFC 2781, February 2000.  (See http://www.ietf.org/rfc/rfc2781.txt.)</dd><dt class="label"><a name="RFC3066" id="RFC3066" />[RFC3066]</dt><dd>Tags for the Identification of Languages, H. Alvestrand,
RFC 3066, January 2001.  (See http://www.ietf.org/rfc/rfc3066.txt.)</dd><dt class="label"><a name="RFC3629" id="RFC3629" />[RFC3629]</dt><dd> 
UTF-8, a transformation format of ISO 10646,
F. Yergeau, RFC 3629, STD 63, November 2003.  (See http://www.ietf.org/rfc/rfc3629.txt.)</dd><dt class="label"><a name="SOAP-0" id="SOAP-0" />[SOAP-0]</dt><dd>"SOAP Version 1.2 Part 0: Primer",
Nilo Mitra, 
W3C Recommendation  24 June 2003.  (See http://www.w3.org/TR/2003/REC-soap12-part0-20030624/.)</dd><dt class="label"><a name="SOAP-1" id="SOAP-1" />[SOAP-1]</dt><dd>
"SOAP Version 1.2 Part 1: Messaging Framework",
Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau,
Henrik Frystyk Nielsen,
W3C Recommendation  24 June 2003.  (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)</dd><dt class="label"><a name="SOAP-2" id="SOAP-2" />[SOAP-2]</dt><dd>
"SOAP Version 1.2 Part 2: Adjuncts",
Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau,
Henrik Frystyk Nielsen,
W3C Recommendation  24 June 2003.  (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.)</dd><dt class="label"><a name="SOAP-AF" id="SOAP-AF" />[SOAP-AF]</dt><dd>
"SOAP 1.2 Attachment Feature",
Henrik Frystyk Nielsen, Hervé Ruellan, W3C Working Group Note 8 June 2004.  (See http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/.)</dd><dt class="label"><a name="SOAP-EB" id="SOAP-EB" />[SOAP-EB]</dt><dd>"SOAP Version 1.2 Email Binding",
Highland Mary Mountain, Jacek Kopecky, Stuart Williams, Glen Daniels, Noah Mendelsohn,
W3C Note 3 July 2002.  (See http://www.w3.org/TR/2002/NOTE-soap12-email-20020703.)</dd><dt class="label"><a name="UDDI" id="UDDI" />[UDDI]</dt><dd>
"UDDI Version 3.0 Published Specification",
Tom Bellwood, Luc Clément, David Ehnebuske, Andrew Hately, Maryann Hondo,
Yin Leng Husband, Karsten Januszewski, Sam Lee, Barbara McKee, Joel Munter,
Claus von Riegen, 19 July 2002.  (See http://uddi.org/pubs/uddi_v3.htm.)</dd><dt class="label"><a name="UTR10" id="UTR10" />[UTR10]</dt><dd>"Unicode Technical Standard #10: The Unicode Collation Algorithm",
Mark Davis, Kenneth Whistler, Version 4.0, Updated 08 January 2004.  (See http://www.unicode.org/reports/tr10/.)</dd><dt class="label"><a name="UTR15" id="UTR15" />[UTR15]</dt><dd>"Unicode Technical Standard #15: Unicode Normalization Forms",
Mark Davis, Martin Dürst, Version 4.0.0, Updated 17 April 2003.  (See http://www.unicode.org/reports/tr15/.)</dd><dt class="label"><a name="WSA" id="WSA" />[WSA]</dt><dd>"Web Services Architecture",
David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, Michael Champion,
Chris Ferris, David Orchard,
W3C Working Group Note 11 February 2004.  (See http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.)</dd><dt class="label"><a name="WSAG" id="WSAG" />[WSAG]</dt><dd>"Web Services Glossary", Hugo Haas,
Allen Brown, 
W3C Working Group Note 11 February 2004.  (See http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/.)</dd><dt class="label"><a name="WSAR" id="WSAR" />[WSAR]</dt><dd>
"Web Services Architecture Requirements",
Daniel Austin, Abbie Barbir, Christopher Ferris, Sharad Garg,
W3C Working Group Note 11 February 2004.  (See http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211/.)</dd><dt class="label"><a name="WSAUS" id="WSAUS" />[WSAUS]</dt><dd>
"Web Services Architecture Usage Scenarios",
Hao He, Hugo Haas, David Orchard, W3C Working Group Note 11 February 2004.  (See http://www.w3.org/TR/2004/NOTE-ws-arch-scenarios-20040211/.)</dd><dt class="label"><a name="WSDL-B" id="WSDL-B" />[WSDL-B]</dt><dd>"Web Services Description Language (WSDL) Version 1.2 Part 3: Bindings",
Jean-Jacques Moreau, Jeffrey Schlimmer, 
W3C Working Draft 11 June 2003.  (See http://www.w3.org/TR/2003/WD-wsdl12-bindings-20030611/.)</dd><dt class="label"><a name="WSDL-V20" id="WSDL-V20" />[WSDL-V20]</dt><dd>"Web Services Description Language (WSDL) Version 1.2",
Roberto Chinnici, Martin Gudgin, Jean-Jacques Moreau, Jeffrey Schlimmer,
Sanjiva Weerawarana, 
W3C Working Draft 26 March 2004.  (See http://www.w3.org/TR/2004/WD-wsdl20-20040326/.)</dd><dt class="label"><a name="WSRequirements" id="WSRequirements" />[WSRequirements]</dt><dd>"Requirements for the Internationalization of Web Services",
Addison Phillips, W3C Working Draft 17 December 2003.  (See http://www.w3.org/TR/ws-i18n-req/.)</dd><dt class="label"><a name="XFORMS" id="XFORMS" />[XFORMS]</dt><dd>"XForms 1.0",
Micah Dubinko, Leigh L. Klotz, Jr., Roland Merrick, T. V. Raman, 
W3C Recommendation 14 October 2003.  (See http://www.w3.org/TR/2003/REC-xforms-20031014/.)</dd><dt class="label"><a name="XHTML" id="XHTML" />[XHTML]</dt><dd>"XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)", 
W3C Recommendation 26 January 2000, revised 1 August 2002.  (See http://www.w3.org/TR/xhtml1/.)</dd><dt class="label"><a name="XML" id="XML" />[XML]</dt><dd>"Extensible Markup Language (XML) 1.0 (Third Edition)",
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau,
W3C Recommendation 04 February 2004.  (See http://www.w3.org/TR/2000/REC-xml-20001006.)</dd><dt class="label"><a name="XML-JP" id="XML-JP" />[XML-JP]</dt><dd>
"XML Japanese Profile", MURATA Makoto, W3C Note 14 April 2000.  (See http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/.)</dd><dt class="label"><a name="XMLS-2" id="XMLS-2" />[XMLS-2]</dt><dd>
"XML Schema Part 2: Datatypes",
Paul V. Biron, Ashok Malhotra, W3C Recommendation 02 May 2001.  (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)</dd></dl></div><div class="div1">
<h2><a name="IDAEOUO" id="IDAEOUO" />B Acknowledgements (Non-Normative)</h2><p>This document is the work of the Web Services Task Force
 of the W3C Internationalization Working Group.</p><p>The example in <a href="#S-022">I-022</a> was taken directly from an example by Mark Davis, IBM, and is used by his permission.</p></div><div class="div1">
<h2><a name="heisei" id="heisei" />C Heisei (Non-Normative)</h2><p>The imperial Calendar is commonly used in Japan.  Heisei is the current era,
and it started on January 8th, 1989. Year 2002 is Year Heisei 14.
Showa is the previous era, which ended on January 7th, 1989 or Showa 64.</p></div></div></body></html>