Closed benlangfeld closed 10 years ago
Tagging @crienzo.
There's a draft for a CPA spec here. This is mostly complete and I think we should use it as the basis for formal specification. @crienzo @mpermar @loopingrage Any concerns with what's documented there?
Using SRGS seems a little weird. I can go with that if necessary, but it would be easier for me if we had a different document type or if we used a new component.
I agree it's a little weird. The motivation was this:
If anyone knows of an appropriate document format, I'd love to hear it. It's something I feel should have the potential to become a standard such that CPA vendors might implement it independently of Rayo for use via MRCP.
No concerns on this side. All I can say is that our rayo server does currently follow that spec. and all stuff documented there is working.
OK, if this is already working, then I can implement on my server.
I've written a first draft of an extension specification for CPA. This has some minor differences from the version in the wiki, but it still uses the special SRGS grammar format. I will be putting some thought into an alternative, simpler format to replace this later today.
The draft spec has been updated to use special URIs instead of the SRGS grammars previously, like so:
<iq from='juliet@capulet.lit/balcony'
to='9f00061@call.shakespeare.lit'
type='set'
id='h7ed2'>
<input xmlns='urn:xmpp:rayo:input:1' mode='cpa'>
<grammar url="urn:xmpp:rayo:cpa:speech:1?maxTime=4000;minSpeechDuration=4000;minVolume=10;finalSilence=2000;terminate=true" />
<grammar url="urn:xmpp:rayo:cpa:dtmf:1" />
</input>
</iq>
I wonder wether the mode attribute should move from <input/>
to <grammar/>
? The only use case for it is when grammars are referenced by URL to avoid the Rayo server having to fetch the grammar to inspect its type, much like the content-type attribute.
My only use case for using input mode is to decide whether the server needs to parse the grammar or pass it along to an MRCP server.
@crienzo I figure this is what you're referring to. More generally I think this should be dependent only on the recognizer
attribute which can be used to decide which recognizer to route to.
I'll open a new issue on this, but since it's backward incompatible I won't incorporate it immediately.
I think everyone is satisfied with the current spec and I'll submit it to the XSF for publishing today. They will take up to 2 weeks to publish it.
This is a marker for discussion. I'll add my thoughts over the next couple of days.