[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue maint-7 (forwarded 3)
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 ...
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]