RE: USD sections 6.4.4 and 6.6.1

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- )

Received on Wednesday, 17 March 2004 15:32:12 UTC