Subject: RE: [Speechsc] VoiceXML <grammar> weight attribute

From: Eric Burger <[email-masked]>
Date: Fri, 4 Feb 2005 17:34:17 -0500

Any thoughts on this?

> -----Original Message-----
> From: Jeff Kusnitz [mailto:[email-masked]]
> Sent: Thursday, January 20, 2005 4:31 PM
> To: [email-masked]
> Subject: [Speechsc] VoiceXML <grammar> weight attribute
> 
> 
> In the VoiceXML 2.0, the <grammar> tag has been extended to include a 
> weight attribute to allow developers to bias grammars 
> (section 3.1.1.3). 
> The current DEFINE-GRAMMAR request doesn't have a "weight" 
> header though, 
> so it's not possible for a VoiceXML browser to do anything with the 
> <grammar>'s weight attribute.  Is this an oversight?  Is it 
> too late to 
> add "weight" to the DEFINE-GRAMMAR request?
> 
> Thanks,
> Jeff
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Dave Burke" <[email-masked]>
Date: Fri, 4 Feb 2005 23:40:08 -0000

Seems reasonable to me. The MRCP client workaround (inserting weights
uniformly into VoiceXML inline grammars or forcing reflection of external
grammar URIs to do same) is untenable. We already have a "Weight" header for
voice enrollment... Editorial: Is the ABNF WEIGHT rule defined? It should
allow for the VoiceXML 2.0 requirement of n, n., .n, n.n

-- Dave

---

From: Sarvi Shanmugham <[email-masked]>
Date: Mon, 14 Feb 2005 16:12:24 -0800

The W3C grammar spec contains a weight attribute. Which should address 
the need well.

I am not sure if it makes sense to add a weight header field to a 
DEFINE-GRAMMAR method as weights seems to make more sense where it is 
being refered/used by other grammars. I mean, where a higher level 
grammar refers to these individual grammars and assigns relative weights 
to them.

Does it make sense to "define" a grammar with a fixed weight. Doesn't it 
actually more sense to specify weight a set of grammars is being used in 
a RECOGNIZE?

I would lean towards not adding a weight header for this purpose in 
MRCPv2 when the W3C grammar spec addresses this problem..

Sarvi

---

From: Jeff Kusnitz <[email-masked]>
Date: Mon, 14 Feb 2005 17:55:24 -0800

I tend to disagree.  The SRGS "weight" attribute can only be used on an 
<item>.  For a VoiceXML browser to handle the weight attribute, it would 
probably have to combine all of the grammars for a given turn into a 
single grammar along with their respective weights.  In principle that 
would work take care of the weights, but it would cause problems for 
prioritization (section 8.5.1 - recognizer data) - grammar prioritization 
would become rule prioritization, which is probably too much to ask of 
reco engines and grammar compilers.

Thanks,
Jeff

[email-masked] wrote on 02/14/2005 04:12:24 PM:

> The W3C grammar spec contains a weight attribute. Which should 
> address the need well.
> 
> DEFINE-GRAMMAR method as weights seems to make more sense where it 
> is being refered/used by other grammars. I mean, where a higher 
> level grammar refers to these individual grammars and assigns 
> relative weights to them. 
> 
> Does it make sense to "define" a grammar with a fixed weight. 
> Doesn't it actually more sense to specify weight a set of grammars 
> is being used in a RECOGNIZE?
>

---

From: Sarvi Shanmugham <[email-masked]>
Date: Mon, 14 Feb 2005 23:07:13 -0800

What doesn't seem to make sense is to attribute a particular weight to a 
grammar in the DEFINE-GRAMMAR method. Which means that the weight would 
be associated with the grammar for life of that session, irrespective of 
what other grammars(with their weights) might be refered in the 
RECOGNIZE command along with this grammar.

Is this the behaviour you are expecting.

Sarvi

---

From: Jeff Kusnitz <[email-masked]>
Date: Fri, 18 Feb 2005 07:09:51 -0800

That's a good point - I was thinking that in a typical VoiceXML app a 
grammar would never change so it wouldn't matter whether the weight was 
associated with the DEFINE-GRAMMAR or RECOGNIZE request, but that's wrong. 
 An external grammar can be referenced from many places in the same 
VoiceXML code, with different weights each time.

In terms of how to include weight information along with grammars on a 
RECOGNIZE request, how does a multipart document sound - something like 
this:

        ...
        Content-Type: multipart/mixed; boundary="break" 
 
        --break 
        Content-Type: text/uri-list 
        Content-Length: 176 
        Grammar-Weight: 0.5
        http://www.example.com/Directory-Name-List.grxml 
 
        --break 
        Content-Type: text/uri-list 
        Content-Length: 176 
        Grammar-Weight: 0.2
        http://www.example.com/Department-List.grxml 
        http://www.example.com/TAC-Contact-List.grxml 
 
        --break 

What do you think?

Thanks,
Jeff

Sarvi Shanmugham <[email-masked]> wrote on 02/14/2005 11:07:13 PM:

> What doesn't seem to make sense is to attribute a particular weight 
> to a grammar in the DEFINE-GRAMMAR method. Which means that the 
> weight would be associated with the grammar for life of that 
> session, irrespective of what other grammars(with their weights) 
> might be refered in the RECOGNIZE command along with this grammar.
>

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 18 Feb 2005 11:03:19 -0800

This would require rewriting the multi-part mime ABNF specification. 
Wouldn't it?

How about adding a new header, say One-Of-URI-Rule-Id.

One-Of-URI-Rule-Id
This header field MAY be specified in the RECOGNIZE command carrying a 
single URI or grammar block in its mime body. This header refers to a 
specific rule-id in the grammar specified in the mime-body as the list 
of grammars to activate. This rule-id MUST be a <one-of> rule-id and the 
listed items MUST ALL BE grammar-uri-references and MAY NOT be grammar 
token.  This  is considered equivalent  to specifying a  tex/uri mime 
type with a list of grammar URI, but has the additional benefit of  
being able to provide  weights  for  the individual  grammar URIs.

           one-of-uri-tule-id =     "One-Of-URI-Rule-Id"    ":"      
token     ; token is defined in ABNF
     
Usage example:

Example 1:
C->S:MRCP/2.0 479 RECOGNIZE 543257
         Channel-Identifier: 32AECB23433801@speechrecog
         Confidence-Threshold: 0.9
         Fetch-Timeout:20
         One-Of-URI-Rule-Id:rule_list
         Content-Type: application/srgs+xml
         Content-Length: 176

         <?xml version="1.0"? version="1.0" mode="voice" root="basicCmd">
         <rule id="rule_list" scope="public">
             <one-of>
                 <item weight=10>
                     <ruleref 
uri="http://grammar.example.com/world-cities.grxml#canada"/>
                </item>
                <item weight=1.5>
                    <ruleref 
uri="http://grammar.example.com/world-cities.grxml#america"/>
                </item>
               <item weight=0.5>
                    <ruleref 
uri="http://grammar.example.com/world-cities.grxml#india"/>
               </item>
           </one-of>
        </rule>

What do you think.

Sarvi

Jeff Kusnitz wrote:

>>prioritization (section 8.5.1 - recognizer data) - grammar 
>>    
>>
>prioritization 
>  
>

---

From: "Dave Burke" <[email-masked]>
Date: Wed, 23 Feb 2005 22:53:49 -0000

Interesting approach. The One-Of-URI-Rule-ID header seems superfluous though. In other words, the MRCP spec could just have a short "Implementation Note" describing a way of assigning weights to individual grammars by using a simple, valid, SRGS grammar with weighted alternatives. However, this approach doesn't allow session: grammars to be included.

Yet another possibility (he writes with trepidation) would be to introduce a URI parameter, e.g.

 session:[email-masked];weight=1
 http://www.example.com/Directory-Name-List.grxml;weight=2

-- Dave
  ----- Original Message ----- 
  From: Sarvi Shanmugham 
  To: Jeff Kusnitz 
  Cc: [email-masked] ; Eric Burger 
  Sent: Friday, February 18, 2005 7:03 PM
  Subject: Re: [Speechsc] VoiceXML <grammar> weight attribute

  This would require rewriting the multi-part mime ABNF specification. Wouldn't it?

  One-Of-URI-Rule-Id
  This header field MAY be specified in the RECOGNIZE command carrying a single URI or grammar block in its mime body. This header refers to a specific rule-id in the grammar specified in the mime-body as the list of grammars to activate. This rule-id MUST be a <one-of> rule-id and the listed items MUST ALL BE grammar-uri-references and MAY NOT be grammar token.  This  is considered equivalent  to specifying a  tex/uri mime type with a list of grammar URI, but has the additional benefit of  being able to provide  weights  for  the individual  grammar URIs.

             one-of-uri-tule-id =     "One-Of-URI-Rule-Id"    ":"      token     ; token is defined in ABNF
        
  Usage example:

  Example 1:

           <?xml version="1.0"? version="1.0" mode="voice" root="basicCmd">
           <rule id="rule_list" scope="public">
               <one-of>
                   <item weight=10>
                       <ruleref uri="http://grammar.example.com/world-cities.grxml#canada"/>
                  </item>
                  <item weight=1.5>
                      <ruleref uri="http://grammar.example.com/world-cities.grxml#america"/>
                  </item>
                 <item weight=0.5>
                      <ruleref uri="http://grammar.example.com/world-cities.grxml#india"/>
                 </item>
             </one-of>
          </rule>

  What do you think.

  Sarvi

  Jeff Kusnitz wrote: 

        ...
 
        --break 
 
        --break 
 
        --break 

What do you think?

Thanks,
Jeff

Sarvi
Jeff Kusnitz wrote: 

    
prioritization 

Thanks,
Jeff

Sarvi
Eric Burger wrote: 
Any thoughts on this?

-----Original Message-----
From: Jeff Kusnitz [mailto:[email-masked]]
Sent: Thursday, January 20, 2005 4:31 PM
To: [email-masked]
Subject: [Speechsc] VoiceXML <grammar> weight attribute

Thanks,
Jeff

    

------------------------------------------------------------------------------