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 Wednesday, 16 March 2005 01:01:08 UTC