It is worthwhile to review
the reporting and handling of invalid grammars. Consider a recognize
containing two invalid URIs and referencing two invalid grammars. The
message and responses might look something like
this:
C->S:MRCP/2.0 RECOGNIZE 543260
Channel-Identifier:32AECB23433801 at speechrecog
Content-Type:text/uri-list
Content-Length:???
session:http://www.example.com/bad_uri_404.gxml
session:http://www.example.com/bad_uri_408.gxml
session:http://www.example.com/bad_grammar1.gxml
session:http://www.example.com/bad_grammar2.gxml
S->C:MRCP/2.0 543260 407 IN-PROGRESS
Channel-Identifier:32AECB23433801 at speechrecog
Completion-Cause:009 uri resolution problem
Failed-URI-Cause:404
Failed-URI:http://www.example.com/bad_uri_404.gxml
S->C:MRCP/2.0 543260 407 IN-PROGRESS
Channel-Identifier:32AECB23433801 at speechrecog
Completion-Cause:009 uri resolution problem
Failed-URI-Cause:408
Failed-URI:http://www.example.com/bad_uri_408.gxml
S->C:MRCP/2.0 543260 407 COMPLETE
Channel-Identifier:32AECB23433801 at speechrecog
Completion-Cause:005 grammar violates schema
Failed-URI:http://www.example.com/bad_grammar1.gxml
Failed-URI:http://www.example.com/bad_grammar2.gxml
Sarvi>> The
above messaging is not supported today. A 407 means there was a failure and
should be return request-state COMPLETE. There will no more messages or
events.
(1) Is there any benefit
to having separate 'Failed-URI-Cause' and 'Failed-URI' messages? These
should be combined. Then, the messages for the first two errors could
also be merged.
S->C:MRCP/2.0 543260 407 IN-PROGRESS
Channel-Identifier:32AECB23433801 at speechrecog
Completion-Cause:009 uri resolution problem
Failed-URI:http://www.example.com/bad_uri_404.gxml
404
Failed-URI:http://www.example.com/bad_uri_408.gxml 408
[Sarvi>>] As of
today in a failure response there can be one Failed URI and an associated
Failed URI-Cause. If we want to support more then one such URI, we need to
club the failure cause together with the uri as consecutive headers and
then allow for more than one set of these.
If we want to support more
detailed failure information, I like Dave Oran's suggestion on the topic of
SPEAK requests on a different thread.
Anyway, for the current spec
though the first URI failure and its cause is what is specified
here.
(2) The specification does
not dictate today whether a client must process all the grammars before
RECOGNIZE / DEFINE-GRAMMAR are complete. The MRCP specification should
say this: RECOGNIZE MAY terminate after the first error but DEFINE-GRAMMAR
SHOULD attempt to process the entire list of grammars.
[Sarvi>>] I believe the DEFINE-GRAMMAR
should load and compile grammar before returning a COMPLETE
response. Now, I don't believe we need to specify whether the recognizer
should load the entire grammar and compile even if there are URI
failures. It should be fine if the recognizer stops its load/compile
opertion at the first sign of error and return that URI and cuase code. When
we do support more failed uri headers or the detailed error block suggested by
Dave, the recognizer is free to do what ur suggesting. There is no point
enforcing it now.
I believe the RECOGNIZE should
load and compile grammar before returning a response. If it was
successful it would be 200 and later come back with a RECOGNITON-COMPLETE
event. Else it would be failure
response.
If the above is not apparent in
the document, it will be
clarified.
(3) What is the difference
between 004 (grammar-load-failure) and 005
(grammar-compilation-failure)? Would a client ever care? If the
answer is no, then 004 should be retained and 005 eliminated since load is
required and compilation is an implementation detail.
[Sarvi>>] My understading was that
depedning on the recognizer/vendor there is a differntiation between compile
failure(005). and failure to be load a previously compiled grammar into
the recognizer(004). I would suggest leaving it as is, unless I hear more
feed back saying that this causing
problems.
(4) More failure examples
in the specification would be helpful.
Time
permitting.
Thx,
Sarvi