OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[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