Hi,
IMHO, not all outputs of services of the form tr1+tr2 can be resolved by the
intermediary .
Well, you could define a new service, called "combine", and send
tr1(A) and tr2(A) to "combine" and label the result "tr1,2(A)".
As you point out, it's not clear that any useful "combine" services
exist.
One example 'combine' service that I can think of is a 'successive
translation service'. Assume that the user is looking for translating from an
Indian language to European - it is likely that English may be used an
intermediate. So a service(Indian to English) + (English to French) would
effectively give a service of the form (Indian to French).
The cases where the 'merge' can be easily performed by the intermediary should
also be derived using the rules... For example, the output of a service that
works only with the HTML tags could easily be merged with another that purely
works on the content/body ... Some way of expressing this fact in the rule
language would probably help the intermediary in makinbg a decision.
However, what I don't understand is how this affects the
requirements for a callout protocol, except insofar as demuxing
labels are applied to things like "A", "tr1(A)", and "tr2(A)".
It seems very simple to assign channel labels and descriptors
covering channel groupings. The requirement should cover the
necessity of associating each data element with a channel,
shouldn't it?
my 2 cents.
regards
Geetha