From Dave Burke on March 25:

I'm OK with you proposal (I understand the need for content model flexibility 
to permit the different use-cases). However, don't we need <decision> under 
each voiceprint given the identification / multi-verification cases? i.e. at 
any given point of time there is a decision state associated with each 
voiceprint being considered?

[Dan's reply]:
Yes, but by the nature of verification/identification I think we can assume 
that only one voiceprint will be accepted at any given time, right?  All the 
others must be rejected or unknown.

Do you have a use case that would give different results?

[Dave's reply back]:
I was thinking of two points:

1. Even if only one voiceprint was accepted at any given time, the others 
would either be rejected or undecided and that the results ought to be 
explicit in expressing that (i.e. there would be a <decision> for each 
voiceprint). My understanding is that your proposal implies that an omitted 
<decision> is the same as <decision>rejected</decision> or 
<decision>undecided</decision>?

2. The (perhaps edge) case in  multi-verification where more than one 
voiceprint is accepted.

Supercedes Issue 65-14.

From Issue 65-14:
14. What kind of values does <decision> take when (a) training has been 
performed or (b) for multi-verification (can more than one voice-print 
be "accepted"?)
[Sarvi>>] For training, I don't think any of the <voiceprint> elements should 
contain a <decision> element. For multiverification result, the value would 
could be rejected, accepted and undecided.  I believe there should be only one 
<voice-print> with a decision element of the above possible values.

 

DB> Sorry - my query is only relevant to training. Perhaps 11.5.4 should then 
have a sentence clarifying that <decision> is not present for training results?

From Dan Burnett on 3/24/06:
...
To accommodate all of the use cases presented over the past few years, I have 
the following proposal:

We permit <adapted> under only the first <voiceprint>, and make it optional.  
As in -09, it is only returned for a verification (and not
training) result.
We permit <incremental> and require <cumulative> under all <voiceprint> 
elements.
Both <incremental> and <cumulative> can contain the same set of elements under 
the first <voiceprint> (which I'll temporarily name "Set A"), and both 
<incremental> and <cumulative> can contain the same set of elements under all 
but the first <voiceprint> (which I'll temporarily name "Set B").

Set A:
- may contain <decision>, <utterance-length>, <device>, <gender>, and 
<verification-score>.  <verification-score> is required.  <decision> is 
required under one or the other of <incremental> and <cumulative>, but not 
both.  It is only returned for a verification (and not training) result.  All 
other elements are optional under both <incremental> and <cumulative>.

Set B:
- may contain <utterance-length>, <device>, <gender>, and <verification-
score>.  <verification-score> is required.  All other elements are optional.

Consequences of the proposal:
- the content model is more permissive than what both the text and schema 
permit in -09, except
1) it limits <decision> to only occur once in the entire result, and that only 
in a verification result (as opposed to training), and
2) it requires <verification-score> under all <incremental> and <cumulative> 
elements anywhere in the result.