Re: FtF McKenna changes

Use the attached changes for I-026 (better address example from UDDI).

Question: UDDI (http://uddi.org/pubs/uddi_v3.htm) has quite a bit of
I18n in place (xml:lang, sorting (poor description, but present,
handling Intl address formats)).  Do we need to mention this -
duplicate, referral, or new - in i18n-ws?  I'm having trouble figuring
out how to include UDDI Section 5.1 Inquiry API Set
(http://uddi.org/pubs/uddi_v3.htm#_Toc42047281) in I-026 "Searching for
Web Services" other than a "Best Practices Note"

Mike____


Mike McKenna wrote:

> Here are my changes, comments - I-017, I-018, I-019, I-020, I-026,
> I-027
>
> I've indicated below where these sections may be applicable in the new
> outline.
>
> Cheers,
>
> Mike____
>
> "Addison Phillips [wM]" wrote:
>
> > new activity: provide GEO information to GEO.
> > what is purpose of this document?
> > what do we accomplish here?
> >  x New Outline
> >    What's in
> >    What's out
> >  x What's by reference (info)
> >    New Use Cases (use case)
> >    Reorder from existing doc to new sections.
> >
> > 1. Intro to document.
> > 2. Intro to Web Services
> >   - basic framework (description of process)
> >   - pointers to WS core documents
> >   - definition of a Web Service
> >   - overview of SOAP, WSDL, UDDI, SOAP Features, MEPs, etc.
> > 3. Intro to Internationalization (definitions for WS discussion)
> >   - what is internationalization
> >   - why internationalization (two audiences)
> >     - why not ad hoc (need for interoperability discussion)
> >   - what is human language
> >   - what is a locale/international preferences
> >   - XML Schema (locale independence) vs. locale dependent data
> >     -
> >   - mention RFC2277 ;-)
> > 4. WS internationalization issues
> >   - locale patterns in Web services
> >     - locale neutral
> >     - service determined
>
>         I-018
>
> >
> >     - user(caller) influenced
> >     - data driven (Martin)
>
>         I-017, I-018
>
> >
> >   - legacy issues
> >     - encoding handling
> >       - application/soap+xml and charset parameter (info)
> >       - XML document declaration (info)
> >       - what if ultimate application has encoding limitations (use
> case)
> >       - attachments (use case)
> >     - Pandora's box: non-internationalized data structures
> (later)(placeholders)
> >
> > 5. For Implementers of WS Providers, Tools, and Servers
> >   - Providing locale negotiation (info)
>
>         I-020
>
> >
> >   - Providing support for locale patterns (use case) (Addison)
> >   * soap-header requirement?
>
> >
> >   * standard for locale-pattern communication in WSDL requirement?
>
> >        I-018, I-019
>
> >
> >   - Faults and the Reason Text Element (use cases)(extant)
> >   - UDDI search and multilingual text (use case) (Mike)
> (placeholder)
>
>         I-026
>
> >
> >   - introspection of actual "method" to produce WSDL representation
> (JSR-101? Deb placeholder)
> >     - for example java.util.Locale -> lang/region/variant strings?
> > 6. For Implementers of a Web Service
> >   - use locale neutral data structures
>
>         I-017
>
> >
> >   - sorting/collation (use case - curses)
> >     - e.g. curses
> >     - JIS sort vs. U+ sort
> >   - natural language text search (use case)
> >     - keyword searching
> >     - "like"
> >     - e.g. search "Dürst" should return "Duerst" as well (in German)
> >   - how to handle human-readable text in WS
> >     - structuring records (info)
> >     - enumerated values and object naming
> >       - use of default English-like names (info)
> >       - allowing for "display names" vs. internal names (Mike -
> placeholder)
>
>         I-026
>
> >
> >       - etc. (info)
> >     - exchanging language preferences (or assuming it?)
> >       - use metadata
> >       - use separate bindings or services/servers (use case)
> >       - ask for the language
> >       - guess (use case - language default)
>
>         I-020
>
> >
> >   - other i18n-like things: where does this service apply to?
> >     - timezones and time
> >     - calendar
> >       - holiday, and work rules (use case - short example)
> >     - regimes: tax, customs, legal, and other considerations
> >   - other transports (later)
> >     - HTTP accept-language does not exist
> >     - FTP
> >     - SMTP
> >       - MIME tags
> > 7. Message Exchange Patterns and Scenarios (WS-Arch reviews?)
> >     - there are 33 of these (assign 6 to each and review Tuesday)
> > 8. complex scenarios? choreography/BPEL/layering/etc. (Later)
> >   * not done here.
> >
> >
> > Notes:
> > - use cases inline?
> > - change identifying letter of our scenarios to "I" from "S"
> >
> > ===============
> > data driven examples.
> >
> > VAT example (source/target location, what commodity is)
> > unit of measure example (customary vs. SI or maybe currency)
>
>    ----------------------------------------------------------------
>
> 11.3.3 I-017: Data with Additional 'Attributes'
>
> A sender wishes to send monetary data to a receiver. Each of the
> monetary amounts has a specific currency. This usage scenario does not
> raise any requirements. It provides an example of best practice.
>
> SOAP messages are sent to a receiver using XML schema data types such
> as integer, double, float, date, time etc. However, these data types
> may have locale sensitive semantics such as currency and location. In
> order to add data semantics, adding attributes is frequently used for
> XML messaging scenario.
>
> Recommended best practice is to use locale neutral formatted data with
> additional attributes. Final locale sensitive formatting should be
> done in a presentation layer closest to the receiver. Time and date
> are sent using ISO-8601 canonical formatting (YYYY-MM-DD, HH:MM:SS).
> For this example, airline departure time is sent in local time as
> opposed to Universal (UTC) time, as this is most acceptable for
> airline schedule data.  If the data were sent directly from
> application to application, it should send time in UTC format, with a
> local airport timezone presented in time difference from UTC.
> Example: Locale neutral formated data with additional attributes
>
>    <?xml version='1.0' ?>
>    <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
>     <env:Header>
>     </env:Header>
>     <env:Body>
>      <c:getAvailableFlightResponse>
>       <c:price c:currency="USD">123.55</c:price>
>       <c:departuredate c:location="JFK">2003-05-31</c:departuredate>
>       <c:departuretime c:location="JFK">13:30:00</c:departuretime>
>      </c:getAvailableFlightResponse>
>     </env:Body>
>    </env:Envelope>
>
> Another option is to use a structure consisting of two elements for
> RPC scenario using SOAP encoding.
> Example: Locale neutral formated data with additional semantic data
>
>    <?xml version='1.0' ?>
>    <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
>     <env:Header>
>     </env:Header>
>     <env:Body>
>      <c:getAvailableFlightResponse>
>       <c:price>
>        <c:currency>USD<c:currency>
>        <c:amount>123.55</c:amount>
>       </c:price>
>       <c:departuredate>
>        <c:location>JFK</c:location>
>        <c:date>2003-05-31</c:date>
>       </departuredate>
>       <c:departuretime>
>        <c:location>JFK</c:location>
>        <c:time>13:30:00</c:time>
>
>       </departuretime>
>      </c:getAvailableFlightResponse>
>     </env:Body>
>    </env:Envelope>
>
> Applies to: Web services in general
>
> 11.3.4 I-018: Data with Default 'Attribute'
>
> A service is designed around a single currency and therefore did not
> associate financial data with currency symbol or codes. However, the
> responses from this service may in turn be used by multicurrency
> services or incorporated into other messages. Therefore the response
> should be modified to identify the currency used by the service. There
> are 3 possible solutions. Two involve modifying the message format.
> The message can be changed so that a currency element is added to any
> node that has financial data elements. An alternative is to provide
> the currency as an attribute for any financial data. However, it may
> be unacceptable to change the XML message format used by the service.
> A third alternative is to indicate the currency used throughout the
> message in the SOAP header.
>
> 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.  This is recommended best practice for
> commerce systems that must transport transaction information.
> Example: Multiple currencies in SOAP message
>
>    <?xml version='1.0' ?>
>    <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" >
>     <env:Header>
>     </env:Header>
>     <env:Body>
>      <c:purchase>
>       <c:apple>
>        <c:currency>JPY</c:currency>
>        <c:amount>123.55</c:amount>
>       </c:apple>
>       <c:orange>
>        <c:currency>USD</c:currency>
>        <c:amount>325.78</c:amount>
>       </c:orange>
>      <c:peach>
>       <c:currency>EUR</c:currency>
>       <c:amount>36.55</c:amount>
>      </c:peach>
>     </c:purchase>
>    <env:Body>
>    </env:Envelope>
>
> The following is an example which has the default currency in SOAP
> header. It is also possible to specify the default currency attribute
> in SOAP body instead of SOAP header.
>
> Although adding parameter to SOAP body requires design change for
> service interface, adding default value into SOAP header does not
> affect services interface.
>
> This is an acceptable practice when presenting data from legacy
> commerce systems through Web services, for instance a Japanese retail
> or banking site, which conducts all transactions in Japanese Yen
> providing data to an international commerce system.
> Example: Default attribute in SOAP header (the namespace WS-I18N is
> only an example)
>
>    <?xml version='1.0' ?>
>    <env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" >
>     <env:Header>
>      <WS-I18N:WSinternationalization xmlns:WS-I18N="http://example.org/2002/11/21/WS-I18N">
>       <WS-I18N:Currency>JPY</WS-I18N:Currency>
>      </WS-I18N:WSinternationalization>
>     </env:Header>
>    <env:Body>
>     <c:purchase>
>      <c:apple>
>       <c:price>123.55</c:price>
>      </c:apple>
>      <c:orange>
>       <c:price>325.78</c:price>
>      </c:orange>
>      <c:peach>
>       <c:price>36.55</c:price>
>      </c:peach>
>      </c:purchase>
>     </env:Body>
>    </env:Envelope>
>
> Applies to: Web services in general
>
> 11.3.5 I-019: Locale Dependent Datatypes
>
> A sender wishes to send locale dependent data to a receiver for
> regional SOAP messaging or RPC. The receiver needs to process the
> locale dependent data correctly.
>
> 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 Heisei era;
> see Appendix C Heisei).
> Example: Locale sensitive data in regional datatype
>
>    <?xml version='1.0' ?>
>    <env:Header>
>     <WS-I18N:WSinternationalization
>        xmlns:WS-I18N="http://example.org/2002/11/21/WS-I18N">
>      <WS-I18N:dataTypePreference>
>       <ja:JDate xmlns:ja="http//example.org/2003/12/3/ja">EYY-MM-DD</WS-I18N:JDate>
>      </WS-I18N:dataTypePreference>
>     </WS-I18N:WSinternationalization>
>    </env:Header>
>    <env:Body>
>     <departuredate>H14-05-31</departuredate>
>    </env:Body>
>
> Default is locale neutral mode. If a sender and a receiver can
> handshake with each other using the same semantics of locale, sender
> can send locale dependent data to a receiver, and the receiver can
> process the data consistently.
>
> If WSDL can describe locale sensitive datatypes, locale negotiation
> mechanism can be described in WSDL. Is it a requirement applicable for
> interface definitions in WSDL?
>
> Editorial note: KN                              2002-12-10

  Possible datatype: Telephone number, Post code etc. Needs
  feasibility assessment.
>
> There is a difference between data types such as telephone number,
> address elements, post code, forms of address, etc., which can be
> modeled as strings with patterns, and data types such as dates and
> numbers, where a connection with the value space (e.g. of XML Schema)
> may be desirable.  It is the responsibility of the presentation layer
> (outside of SOAP) to properly format locale sensitive data.
>
> WSDL can be used to set a locale header and used as a wrapper for data
> being sent from a legacy system, such as sending address information
> from the Russian Post Office for use by an international postal
> system, where all data sent is from only one locale (ru_RU).
>
> Applies to: WSDL, SOAP, or Localizable datatype
>
> 11.3.6 I-020: Correlation of Data among Services in Different
> Languages
>
> A service is defined using "Service Oriented Architecture Derivative
> Patterns Intermediary" as found in Web Services Architecture document
> [WSA].
>
>      Service "A" is defined as a service that returns status text and
>      deployed on Providers "A1", "A2", and "A3" in different language
>      configurations (locales).
>
>      Provider "B" polls Service "A" on each machine and caches the
>      results.
>
>      Service "B" is defined as a process that returns cached results
>      and is deployed on Provider "B".
>
>      Requesters "C1", "C2", and "C3", each with different language
>      preferences, invoke Service "B" sporadically to obtain data.
>
>      Provider "B" must cache faults and data in all possible
>      negotiated languages since it cannot know in advance which
>      requesters will want what data.
>
>      Provider "B" must send all data to each requester.
>
>      Correlation of data may prove difficult if good I18n priciples
>      are not used and proper tracking of source data locale and
>      Requester locale.
>
> Best practice solution is for Provider "B" to store results from each
> Provider in Service "A", tracking locales of the results. Fault
> messages should be sent to "B" in all Provider Languages.   "C"
> Requesters must identify the locale of expected results.
>
> For a Web service "wrapper" to a legacy client/server application, the
> SOAP header could be used for locale negotiation between Requesters
> and Service.
>
> See I-007 for a similar problem.
>
>
>
> 11.6 Finding Services
>
> 11.6.1 I-026: Searching for Web Services
>
> Searching for Web services depending on language or culture.
>
> Repositories and search-able meta-data (such as UDDI [UDDI]) about Web
> services need to provide support for multiple language searches.
> Transport layer issues do not allow XML data structures to be used for
> resolution, except by reference (e.g. the receiver must down-load a
> separate resource asynchronously to "decode" the preference). Tags on
> this layer may be necessary in place of XML data structures.
>
> Using xml:lang 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 be adorned with
> the xml:lang 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 be adorned
> with the xml:lang attribute and can appear multiple times to allow for
> translations of the policy description.  Providers are encouraged to
> do this for target language markets that their service may support.
>
> Ideally, the entity names in UDDI should also provide and Alternate
> Name in RFC-2277 default language, readable in English.  This provides
> a fall back 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.
>
> (From the UDDI Spec)
>
> The following shows an example of romanization where the primary name
> of the business (a Chinese flower shop) is in Chinese, and its
> alternative name is a romanization:
>
>      <businessEntity . . . >
>
>        ........
>
>        <name xml:lang="zh">黄河花店</name>
>
>        <name xml:lang="en">Huang He Hwa Dian</name>
>
>          .....
>
>      </businessEntity>
>
> The following shows an example of transliteration where the primary
> name of the business is in Chinese, and is a transliteration of its
> alternative English name:
>
>      <businessEntity . . . >
>
>        ........
>
>        <name xml:lang="zh">康�電腦股份有�公�</name>
>
>        <name xml:lang="en">Compaq Computer Taiwan Limited</name>
>
>          .....
>
>      </businessEntity>
>
>
>
>
>
>
>
>
> The following example XML fragment shows an address written in two
> languages, English and Chinese, as indicated by the xml:lang
> attribute:
>
>      <address useType=�Sales office� xml:lang="en"
>      tModelKey=�uddi:…�>
>
>         <addressLine>7 F</addressLine>
>
>         <addressLine>No. 245 </addressLine>
>
>         <addressLine>Sec. 1</addressLine>
>
>        <addressLine>Tunhua South Road</addressLine>
>
>         <addressLine>Taipei </addressLine>
>
>      </address>
>
>      </address><address useType=�Sales office� xml:lang="zh"
>      tModelKey=�uddi:…�>
>
>         <addressLine> 台北市 </addressLine>
>
>        <addressLine> 敦化南路</addressLine>
>
>         <addressLine> 一段</addressLine>
>
>         <addressLine> 245 號</addressLine>
>
>         <addressLine> 7 樓</addressLine>
>
>         …
>
>      </address>
>
>
> Editorial note: KN                                         2002/12/13

  UDDI provides TAXONOMY based on the ISO 3166 Geographic Code System.
>
> 11.6.2 I-027: Fall-Back for Internationalized Web Services
>
> There is no way for the service to find the best appropriate match
> when the user's request cannot be met.
>
> If the sender specified "ja-JP" and "ja-JP" is not available at the
> receiver, what should the fall-back schema be?
>
> Currently, this is implementation defined?  Is there an RFC or W3C
> source we can reference?  Fall back mechanism in HTML?
>
> Editorial note: F2F                                   2002-11-23

  Need to more clearly define this scenario and provide examples.
>
>
>