RE: [business-transaction] Issue maint-9 - proposed solution

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Doug,

Thanks - good points.

1. On the question of invalid (unknown) identifiers, there was an issue
and some discussion in the original progression for invalid ids in the
inferiors-list parameters - in particular, whether it was required to
check all the values for validity before using any of them. This seemed
an unreasonable implementation requirement for prepare_inferiors (for
example) - it should be legitimate for an implementation to start
working through the list sending things before faulting when it came
across the wrong value (which must be a result of a programming error of
some kind). For confirm_transaction, however, we felt that a confirm
decision should not be allowed - this works out to be no problem, since
there will have to be a prepare/checking pass anyway. But for all the
messages, whatever the implementation approach, the error would be found
and the fault thrown.

2. Given that, what should happen if a targetted-qualifiers-list has an
invalid identifier ? Again, that's a symptom of programming error. This
time there are possible implementation approaches that wouldn't
automatically detect the fault (e.g. search the lists only when about to
send to a particular inferior). On the other hand, if the error is
detected, the InvalidInferior fault should be thrown (this will require
tweaking the defining text for that fault). So that comes down to:

    If any of the inferior-identifiers in any of the
"inferior-identifier-list"s of the "Targetted-qualifiers-item"s in the
"targetted-qualifiers" is unknown (does not correspond to an enrolled
Inferior, a FAULT/Invalid-inferior XXXX be returned.

with XXXX either "shall" or "may", depending on whether we force
everyone to check or not. In general, I don't like forcing
implementations to check what can only be user-misuse of an interface
(if you want to send me rubbish, why should I be required to say you are
sending me rubbish), but I suspect most people would prefer "shall" in
this case, so there is consistent behaviour.

3. On the question of duplication of an identifer in different items,
that you mentioned in the meeting, I was thinking of adding:

If an inferior-identifier occurs in the "inferior-identifier-list" of
more than one "Targetted-qualifiers-item", the qualifiers for all such
"Targetted-qualifiers-item" shall be included in the
PREPARE/CONFIRM/CANCEL message.

4. Duplicates within the same list (of any of the various kinds of list)
- I don't think we'ed ever thought of this. It's obviously silly (i.e. a
programming error), though such a strange one that I can't imagine
anyone except a tester doing it !  In this case, I really would prefer
to leave it undefined at spec level, and not force every occurrence to
be checked. Perhaps a general statement that the behaviour is undefined
and implementations are free to ignore the duplicate or throw a General
fault.

That's really a separate issue - do you want to raise it as such ?

Peter


> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@Sun.COM] 
> Sent: 06 January 2004 19:33
> To: Furniss, Peter
> Cc: business-transaction@lists.oasis-open.org
> Subject: Re: [business-transaction] Issue maint-9 - proposed solution
> 
> 
> Peter,
> 
> After reading through this alternative solution, I see that 
> the original 
> proposal disallows an unknown inferior identifier in the qualified 
> inferiors list.  In the alternative, an error results only if 
> the base 
> inferior list contains an unknown inferior -- not one of the 
> inferiors 
> identified in the targetted qualifiers list.  Was allowing unknown 
> inferiors in the inferior identifier lists within the targetted 
> qualifiers list intentional?
> 
> This is somewhat separate from the issue we discussed on the call. 
> Regardless of whether unknown inferiors result in errors within the 
> targetted qualifiers list, the text should cover the 
> possibility of the 
> same inferior identifier appearing in multiple targetted qualifier 
> items.  It may also be worth noting in the text that this 
> option appears 
> for readability or bandwidth purposes only since this 
> allowance does not 
> increase the possible (merged) lists of qualifiers sent to each 
> inferior.  One can always create a canonical list of 
> targetted qualifier 
> items that only mention each inferior once.
> 
> A more general question: Does the current text say anything for or 
> against listing the same inferior (or qualifier, transaction, 
> whatever) 
> multiple times in the same list?  Intuitively, this 
> possibility would be 
> irrelevant (that is, should result in identical behaviour to a list 
> without duplicates) except that an occurrence could mess up an 
> implementation that had not considered the possibility.
> 
> thanx,
> 	doug
> 
> On 06-Jan-04 07:31, Furniss, Peter wrote:
> 
> > I had some further thoughts on this and a discussion with Robert 
> > Clarke
> > here, and I think this second solution might be better. It has a 
> > separate list of targetted qualifiers, so there isn't 
> confusion about 
> > what happens in an Atom, and its easier to send the same 
> qualifier to 
> > several inferiors.
> >  
> > Also uploaded, as : 
> > 
> http://www.oasis-open.org/committees/download.php/4894/maint9_alternat
> > ive_solution.doc
> >  
> > As well as being simpler (probably), I've remembered to make the 
> > changes
> > to PREPARE_INFERIORS this time.
> > What I haven't remembered was to make the corresponding 
> changes in the 
> > XML, but that just works out fairly mechanically. (Alex is 
> rather more 
> > than a mechanic, though :-)
> >  
> > By the way, OASIS have just upgraded their document server 
> and it is a
> > *lot* faster now (i.e. it's actually usable)
> >  
> > Peter
> > 
> >     -----Original Message-----
> >     *From:* Furniss, Peter
> >     *Sent:* 06 January 2004 13:56
> >     *To:* business-transaction@lists.oasis-open.org
> >     *Subject:* [business-transaction] Issue maint-9 - proposed 
> > solution
> > 
> >     Happy New Year to all BTP-ers.
> >      
> >     As requested by the last BT TC meeting (and apologies 
> for not doing
> >     before), I've drafted some text as a solution to maint-9, about
> >     qualifiers for particular inferiors on 
> CONFIRM_TRANSACTION. Since it
> >     includes several changes to the explanatory paragraphs 
> for C_T which
> >     were clearer using change-marking, I've uploaded it as a Word 
> > document :
> >      
> >      
> > 
> http://www.oasis-open.org/committees/download.php/4891/2004-01
-01.maintissue9_solution.doc
>      
>     (that's the public uri, so you won't need your OASIS username/pw
to
>     get at it.)
>      
>     Peter
>      
>     ------------------------------------------
>     Peter Furniss
>     Chief Scientist, Choreology Ltd
>     web: http://www.choreology.com <http://www.choreology.com/>
>     email: peter.furniss@choreology.com
>     <mailto:peter.furniss@choreology.com>
>     phone: +44 870 739 0066
>     mobile: +44 7951 536168
>