Issue maint-7 (forwarded 4)

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

fourth element of conversation

-----Original Message-----
From: Ceponkus Alex - External Address 
Sent: 08 January 2004 17:57
To: Doug Bunting; Furniss, Peter
Subject: Re: [business-transaction] BTP issue maint-7


inline...

Doug Bunting wrote:
> Alex,
> 
> Hmm, this is getting a bit confusing.  Perhaps the original comment 
> you
> made
> 
>   > Response requested is not mandatory (minOccurs=0 and specified
>   > default) for enrol/resign/inferior-state/superior-state in the
>   > xml schema but there is no indication that they are optional in
>   > the informal message set.
> 
> needs to be re-examined.  My previous suggestion was simply to 
> complete
> the change you made to the schema so that the schema was consistent.
It 
> makes little sense to have a default for a required element or
attribute.
> 
> Perhaps the default itself should be considered an "indication that 
> they
> are optional"?  Our committee draft document consistently describes
this 
> element as having a default value.  Removing that default would seem 
> more work than correcting the informal message set for this attribute.

> In other words, because the informal message set is not consistent
with 
> either the text or the schema, it should be the one to change.

I agree, having a default implies that the element can be optional.  It 
is probably true to say that an optional response-requested was the 
original intent.


> Generally, the informal message set provides no indication of default
> values at all.  Lines 3483 and 3484 of the specification mention 
> defaults but outside the tables.  The corresponding table provides no 
> indication the relevant (must-be-understood and to-be-propagated) 
> attributes are optional.

Peter and I had a discussion in the fall about indicating default values

in the informal XML by either bolding or underlining the default value.

Peter: Do you recall where we left off?


> Searching for defaults in the specification uncovers some additional
> inconsistencies.  report-hazard has a default of "false" in 
> CONFIRM_ONE_PHASE but no default elsewhere (CONFIRM_TRANSACTION, 
> CANCEL_TRANSACTION).  The informal message set and schema consistently

> have this element as required with no default.  I can see the utility
of 
> a default for any simple Boolean but would understand simply removing 
> one sentence (at line 2525) in the CONFIRM_ONE_PHASE description.
(Going 
> much more general, defaults at the XML instance level force some
amount 
> of schema processing.  I therefore lean toward avoiding the tri-state 
> version that allows missing, false and true.  Either 
> <report-hazard>true</report-hazard> ? or 
> <report-hazard>true|false</report-hazard> are easier to handle than 
> <report-hazard>true|false</report-hazard> ? )

I am happy to go either way on this one.  Was CONFIRM_ONE_PHASE 
report-hazard given a default so the element contents could be the same 
as CONFIRM?  If we don't have a good reason giving it a default, we 
might as well go with consistency.


> An Address apparently has a priority attribute (with a default of 1) 
> to
> order a list of multiple addresses but this attribute does not appear
in 
> the informal message set or schema.  No idea what needs to happen
here.

Do either of you know what is meant by 'highest priority'?  The lowest 
number?   Will an integer suffice for this value or is there a need to 
limit negative numbers (and possibly 0?)

Looks like the following will need to be updated:
- address example on like 3452
- all the informal XML messages that use the same address more than once

(ex: For CONTEXT, superior-address, but not reply-address): CONTEXT, 
ENROL, REDIRECT (although does not make sense for 'old-address'), and 
BEGUN.  (quick pass only, so I probably missed some.)
- XML schema for the same messages.  A couple of options exist: create a

btp:address-with-priority type, or add the priority attribute for each 
instance that requires it.


> The superior-type element has a default of "atom" but that is not even
> indicated in text after the table.  The transaction-type element in a 
> BEGIN should be used to set the superior-type of the created CONTEXT
but 
> does not have a default.  These elements are pretty much Booleans
(have 
> very similar behaviour to an is-cohesion Boolean with a default of 
> false) and I can see the utility of providing that default.  Again,
the 
> smaller change would be to remove one sentence (at lines 2175-2176).
I 
> cannot remember if the protocol provides another in-band mechanism to 
> create a CONTEXT beyond BEGIN (without an associated CONTEXT, of 
> course).  If such a mechanism exists, other choices may be prudent.


Peter: in terms of process, how do you suggest we make updates to the 
informal XML?

Alex