Issue maint-7 (forwarded 3)

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

Third element of conversation

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@Sun.COM] 
Sent: 07 January 2004 20:16
To: Ceponkus Alex - External Address
Cc: Furniss, Peter
Subject: Re: [business-transaction] BTP issue maint-7


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.

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.

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> ? )

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.

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.

thanx,
	doug

On 07-Jan-04 10:54, Alex Ceponkus wrote:

> Hi Peter,
> 
> The main body of the spec states that there is a default value for
> response-requested, implying that it is optional.  See lines 2284-2285

> (from 2002-06-03.BTP_cttee_spec_1.0.pdf) for the Enrol message.
Perhaps 
> the informal XML is incorrect rather than the XML schema?  Can you 
> confirm from the abstract message set whether response-requested is 
> meant to be optional?
> 
> The attached schema is still broken.  Either the minOccurs="0" needs 
> to
> be put back, or default="false" needs to be removed.
> 
> The transaction-identifier error that Doug points out below is fixed 
> in
> the attached schema.
> 
> The informal XML on line 3925 of the spec has a bug...
> 
> 3924 <btp:transaction-identifier>...URI...</btp:transaction-
> 3925 identifier> ?
> 
> should be ...
> 
> 3924 <btp:transaction-identifier>...URI...</btp:transaction-
> 3925 identifier>
> 
> 
> Alex
...