RE: VBWG official response to last call issue

Hello, Martin,

Thanks for your responses.

Regarding the street example, the group has decided to accept your request
and modify it to request a country followed by a city and finally a street
address. This demonstrates the functionality of grammar srcexpr while also
making the example more international-friendly. We hope this satisfies your
request.

We will follow up with your shortly on the IRI issue.

Thanks.

Matt
-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf
Of Martin Duerst
Sent: Tuesday, March 15, 2005 3:30 PM
To: MattO
Cc: www-voice@w3.org; w3c-i18n-ig@w3.org; public-i18n-core@w3.org
Subject: Re: VBWG official response to last call issue



Hello Matt,

At 09:08 05/03/12, MattO wrote:
 >
 >Dear Martin, et al,
 >
 >The Voice Browser Working Group (VBWG) has almost finished resolving the
>issues raised during the last call review of the 28 July 2004 working draft
>of VoiceXML 2.1 [1]. Our apologies that it has taken so long to respond.

Many thanks for your replies. Please note that the mailing list of the I18N
(Core) WG for spec reviews has changed from w3c-i18n-ig@w3.org to either
member-i18n-core@w3.org (for member-only discussions) or
public-i18n-core@w3.org (for publicly visible discussion). I have copied
public-i18n-core@w3.org because www-voice@w3.org is already public.

 >Please indicate before March 17th, 2005 if you are satisfied with the
VBWG's  >resolutions, if you think there has been a misunderstanding, or if
you wish  >to register an objection.

See below.

 >If you will be unable to respond before March
 >17th, please let me know. The Director will appreciate a response whether
or  >not you agree with the resolutions.  >  >Below you will find:  >  > 1)
More information follows about the process we are following.  > 2) A summary
of the VBWG's response to your issues.  >  >Thank you,  >  >Matt Oshry
>Chief Editor, VoiceXML 2.1  >
 >-----------------------------------------------
 >1) Process requirement to address last call issues
 >-----------------------------------------------

 >[1] http://www.w3.org/TR/2004/WD-voicexml21-20040728/

 >-----------------------------------------------
 >2) Issues you raised and responses
 >-----------------------------------------------
 >In http://lists.w3.org/Archives/Public/www-voice/2004OctDec/0032.html you
>raised the following issues which were registered as change request R107.
>Our response is given inline:  >
 >"Abstract: 'VoiceXML 2.1 specifies a set of features commonly implemented
by  >  >Voice Extensible Markup Language platforms. This specification is
designed  >to be fully backwards-compatible with VoiceXML 2.0 [VXML2].'  >
>-> It is not clear to the reader quickly enough that this specification
 >    only describes a diff between VoiceXML 2.1 and VoiceXML 2.0. This
 >    should be made much clearer."
 >
 >VBWG Response: Accepted
 >A sentence was added to the abstract to indicate that the specification
>describes only the set of additional features. In addition a table of the
>elements that were added or enhanced was added to the introduction.

Okay!

 >"Appendix C: 'A conforming VoiceXML document is a well-formed [XML]
document  >  >that requires only the facilities described as mandatory in
this  >specification and in [VXML2].'  >  >-> Similar confusion as above.
Either VoiceXML 2.1 is the diff, or it is
 >    the result of additions. But not both."
 >
 >VBWG Response: Rejected
 >While the VoiceXML 2.1 specification describes only the set of additional
>features that have been frequenty requested and widely implemented -
>VoiceXML 2.1 is built on top of the foundation described in the VoiceXML
2.0  >specification. A conforming VoiceXML 2.1 document is one that meets
the  >requirements described in both the VoiceXML 2.0 and VoiceXML 2.1
>specifications.

This should be okay.

 >"Section 2, street example: In usual Web browsers, for
internationalization  >reasons, usually 'address1', 'address2', are used. Is
there such practice  >for Voice applications? If not, how are addresses in
various locations  >around the world handled? It would be highly desirable
if this example were  >fixed so that it could be used as good practice
worldwide. Same for  >citystate."  >  >VBWG Response: Rejected  >While the
language supports the construction of a dialog that allows the  >user to
specify a location anywhere in the world, the working group feels  >that
extending the existing sample code to demonstrate that functionality  >would
complicate the example unnecessarily. The purpose of the example is to
>demonstrate concisely how to set the srcexpr attribute on grammar.

We are not satisfied with this response.

- We didn't ask to complicate it, just to change it to make it more
   international. What about e.g. asking for a country and
   a city instead of city, state, and street.
- If you really don't want to change it, add some comment such as
   changing "The following example requests a city and state" to
   "The following example requests a city and state, as it would
    be used when asking for an address in the US," and later add
   "This example will have to be changed for addresses in other
    countries."


 >"URIs: The XML Schema at
>http://www.w3.org/TR/2004/WD-voicexml21-20040728/vxml-datatypes.xsd
 >containing the segment:
 >
 ><xsd:simpleType name='URI.datatype'>
 >     <xsd:annotation>
 >         <xsd:documentation>URI (RFC2396)</xsd:documentation>
 >     </xsd:annotation>
 >     <xsd:restriction base='xsd:anyURI'/>
 ></xsd:simpleType>
 >
 >seems to try to restrict anyURIs used in VXML to URIs only. However, there
>are two problems with this approach:
 >1) This is a very poor way of trying to make this restriction,
 >    if the restriction is indeed to be made, an actual pattern
 >    should be specified.
 >2) Such a restriction would rule out the use of IRIs, which would
 >    be a very bad idea with respect to internationalization.
 >So we request that you:
 >- (possibly) add a restriction that just removes space and a few
 >   other ASCII characters allowed in anyURI, but neither in
 >   URIs nor in IRIs.
 >- Say clearly in the spec that wherever the term URI is used,
 >   this isn't restricted to ASCII only, but follows IRIs."
 >
 >VBWG Response: Deferred
 >
 >VoiceXML 2.1 (VXML21) is designed to be completely backwards compatible
with  >VoiceXML 2.0 (VXML2). The VXML21 schema is derived directly from the
VXML2  >schema, and the definition of "URI.datatype" is identical. The VBWG
suggests  >that it would be more appropriate to submit this particular CR to
the VBWG  >as a proposed errata for VXML2. If the CR were adopted for VXML2,
the change  >would be picked up by VXML21 to maintain compatibility.

So we herewith request the following changes to VXML2, which we understand
will be carried over to VXML21:

- Change the XML Schema definition of URI.datatype from:

   <xsd:simpleType name='URI.datatype'>
        <xsd:annotation>
            <xsd:documentation>URI (RFC2396)</xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base='xsd:anyURI'/>
   </xsd:simpleType>

   to:

   <xsd:simpleType name='URI.datatype'>
        <xsd:annotation>
            <xsd:documentation>IRI (RFC3987)</xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base='xsd:anyURI'/>
   </xsd:simpleType>

- Add a reference to RFC 3987

- Update the reference to RFC 2396 to RFC 3986

- Say clearly in the spec that wherever the term URI is used,
   this isn't restricted to ASCII only, actually allows IRIs.

We very much hope that this can be done in time for the next publication of
VXML21.

With kind regards,    Martin.

Received on Thursday, 24 March 2005 20:32:02 UTC