[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Issue 50 - Comment with vote
Alex, With regard to making the schema non-normative, I wouldn't recommend going that far because the schema will (or should) be used to validate BTP constructs at run time, prior to invocation of any BTP specific code. Receivers in particular will parse and (often) validate messages with a generic parser first. The schema can't be overridden by the code invoked later. Therefore, the schema is an important and normative part of the overall BTP infrastructure. As long as we avoid default values (in the schema or in our specification document) that vary depending upon the context, I doubt it matters whether those defaults are expressed in the schema or not. It might make the application logic slightly easier (test for particular values rather than one value or not present) to have the defaults in the schema but that's about it. We avoided the problem case in our resolution of issue 50, making report-hazard mandatory rather than something with a context dependent default. We've also done a good job making the default values for Booleans consistently false. thanx, doug ----- Original Message ----- From: "Peter Furniss" <peter.furniss@choreology.com> To: "BT - spec" <bt-spec@lists.oasis-open.org> Sent: Monday, March 04, 2002 4:19 PM Subject: [bt-spec] Issue 50 - Comment with vote The following is a comment Alex Ceponkus made on his vote for issue 50, which will otherwise be lost in the mailboxes of myself and Bill Pope. I'm assuming he will not mind if I publicise it. (The only other comments that seemed substantive were from Doug Bunting, but since his message was copied to the main list, I'm not intending to forward it). Peter 50: yes .. I agree that the XML spec section needs to be updated, but not the XML schema. I have been trying to only have the basic xml structure reflected in the schema. For example, in Fault, the superior-identifier is only present if this fault is being sent to a superior .. there is no way for that kind of information to be reflected in the schema, so the superior-identifier is just optional. I find the default values fall into this category (however, there is a way to specify default values in the schema, I don't think there is much benefit.) Perhaps we should call the schema 'non-normative' to indicate that the spec body text takes precedence. > -------------------------------------------------------------------- > > Issue 50: Default parameter values > > -------------------- > Description > > Did we ever discuss default values for: > (i) reply requested [false] > > (ii) response-requested [no default as far as I can tell, but I'd > suggest true > if sent before a PREPARE, and false otherwise.] > > (iii) report hazard [false] > > We also need to be consistent on the names: hyphenated or not. > > -------------------- > Proposed Resolution > > In the body of the text, abstract message definitions and the XML > > - Change "reply-requested" to "response-requested" for all uses of the > parameter. > > - "response-requested" has a default of "false" in all cases > > - "report-hazard" has no default value specified. The parameter > is mandatory > in the XML. > > - hyphenate all parameter names consistently . > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC