Re: USD sections 6.4.4 and 6.6.1

OK so, in thinking about SOAP doc structures, I would think about the things we 
recommend putting in the header and those we recommend putting in the body.  BUt 
we talk about that elsewhere in the USD.  Are we just trying to consolidate the 
info?  If we're looking for specifics and examples of SOAP and WSDL docs done in 
an i18n-sensitive way, then it's going to take me a long time, since these are 
documents I never generate.  I'm trying to slog through the WSDL spec right now, 
but I don't think I'll have a firm enough grasp in time to get this done.

I'll focus on my other 2 sections for now.

Andrea

Addison Phillips [wM] wrote:

> Hi Andrea,
> 
> You're first with your assignments! Thanks!!
> 
> I think the word 'documents' in USWD means explicitly SOAP documents or
> their WSDL analogs. In this case, it probably really means 'types' such as
> those described by WSDL (see http://www.w3.org/TR/wsdl20/#eii-types). This
> may actually be a deep topic; too deep to really deal with here? Designing
> internationalized data structures would make a good book length topic :-).
> 
> The timezone examples are fine.
> 
> To be honest, I think we need to decide just how much i18n primer we're
> going to provide in the finished document. The timezone material seems
> important to mention. In depth coverage here might be too much to ask for.
> 
> Best Regards,
> 
> Addison
> 
> Addison P. Phillips
> Director, Globalization Architecture
> webMethods | Delivering Global Business Visibility
> http://www.webMethods.com
> Chair, W3C Internationalization (I18N) Working Group
> Chair, W3C-I18N-WG, Web Services Task Force
> http://www.w3.org/International
> 
> Internationalization is an architecture.
> It is not a feature.
> 
> 
>>-----Original Message-----
>>From: public-i18n-ws-request@w3.org
>>[mailto:public-i18n-ws-request@w3.org]On Behalf Of A. Vine
>>Sent: mardi 16 mars 2004 19:42
>>To: I18n WSTF
>>Subject: USD sections 6.4.4 and 6.6.1
>>
>>
>>
>>OK I have a question -
>>Section 6.4.4 is called "structuring documents"  I've read the
>>entire document
>>again to try and figure out what kind of documents this refers
>>to.  Anyone have
>>an idea?  Are we talking SOAP documents?  That doesn't make sense in the
>>context.  Are we talking about documents provided by the service?
>> I envision a
>>discussion of recommending XML format (in non-recommendation
>>verbiage) and
>>talking about i18n-related information within such a document.
>>But, that seems
>>a little too much like i18n primer material.  So I figure I must
>>be missing the
>>point here.
>>
>>Here's a stab at section 6.6.1 - it's a little pedestrian.  I'll
>>try and come up
>>with something a little more creative, but I guess I'm not overly
>>inspired.  If
>>someone has an idea for a scenario, I'm happy to write it up.
>>
>>6.6.1 Times and Time Zones
>>
>>Time handling in Web services is usually affected by time zones.
>>However, there
>>is no standard parameter to indicate the time zone.  Locales are
>>not useful for
>>determining time zone because there can be many time zones within
>>a given locale.
>>
>>Scenario A:  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
>>xml:lang tag) and
>>the provider returns the current time in that city formatted in
>>ISO 8601 format
>>(hh:mm:ss).
>>
>>Scenario B:  A Web service takes a date/time value in ISO 8601 format
>>(yyyymmddThhmm+hhmm) and the name of a city with an xml:lang tag,
>>and returns
>>the value converted to the specified city's time.
>>
>>Scenario C:  As a sub-process of a calendar service, a Web
>>service inspects
>>multiple calendars 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 calendars store information
>>about their
>>time zones.  The service returns a series of time spans in the
>>ISO 8601 format.
>>
>>
>>--
>>I have always wished that my computer would be as easy to use as
>>my telephone.
>>My wish has come true. I no longer know how to use my telephone.
>>-Bjarne Stroustrup, designer of C++ programming language (1950- )
> 
> 

-- 
I have always wished that my computer would be as easy to use as my telephone. 
My wish has come true. I no longer know how to use my telephone.
-Bjarne Stroustrup, designer of C++ programming language (1950- )

Received on Thursday, 18 March 2004 14:50:58 UTC