> > --EMMA-- > Can we agree the following addition to SpeechRecognitionResult (section > 5.1)? > readonly attribute DOMString emma; > Given the use cases I'm ok with adding the emma attribute. I think it is better if it is of type Document (similar to XmlHttpRequest.responseXML) as there would be far more use cases for parsing the emma result in JS than using it as a string. I also think this should be an optional attribute and the UA can set it to null if the service didn't return EMMA data. The reasoning is that accessing the raw utterance value is far simpler with the JS object (alternative.utterance) than navigating through the emma xml DOM, so the emma attribute will be useful only for those web apps which require additional data from the recognizer and know that the service they are using will be sending that data. --Interpretation-- > I like Satish's suggestion of rendering the interpretation structure as a > native JS object. The only dissenting opinion I heard was that the value > of the interpretation should be readily accessible for developers that > didn't want to traverse slots. > > I thinks both of these needs can be met using the <emma:literal> tag which > sits under <emma:interpretation>. For simple interpretation scenarios > (like basic dictation), the recognizer will populate the <emma:literal> > with the text meaning of the utterance. This will be reflected as a simple > string accessible from the "interpretation" property of the > SpeechRecognitionAlternative. If the EMMA contains slots, these will be > accessible using the JS property syntax (eg interpretation.time). Note > that I don't think EMMA prevents <emma:literal> in parallel with slots. > But I don't think we should change the proposed design either way. > If emma is exposed as a separate attribute, I think that alone is sufficient and no need to represent the same data in another format (i.e. as a JS object). My earlier proposal was to only expose JS objects but since there are valid cases where that wouldn't be sufficient exposing the emma document is ok. I'd prefer we don't inject the interpretation received in SISR into the emma XML as again it is simpler to access it via JS.
Received on Wednesday, 23 May 2012 12:42:51 UTC