This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8283 - Eventing: fault descriptions/semantics are inconsistent
Summary: Eventing: fault descriptions/semantics are inconsistent
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
Keywords: hasProposal
Depends on: 8176
  Show dependency treegraph
Reported: 2009-11-13 20:05 UTC by Gilbert Pilz
Modified: 2010-03-17 11:30 UTC (History)
1 user (show)

See Also:


Description Gilbert Pilz 2009-11-13 20:05:08 UTC
WS-Eventing defines a number of faults in Section 6. Most of these faults are described by text with the pattern "This fault is generated when . . .". Two of these faults (EmptyFilter and UnusableEPR) are described by text with the pattern "This fault MAY be generated when . . ."

1.) Why do some descriptions use the RFC 2119 "MAY" and others do not?

2.) Since the term "generated" means "do something internal and OPTIONALLY transmit the fault", the phrase "MAY be generated" is redundant.

Proposal: Change the descriptions of the faults to use the pattern "This fault MUST be generated when . . ."
Comment 1 Doug Davis 2010-01-10 13:08:51 UTC
Aside from the text mentioned 8176, the only other spot that I found
where we say "MAY generate" or "SHOULD generate" instead of "MUST generate"
is in Transfer:
Such changes could affect elements or attributes that, for whatever reason, the implementation does wish to allow the client to change. An implementation MAY choose to ignore such elements or attributes, or it MAY generate a wst:PutDenied fault.

It looks safe to modify the text in the "Faults" section as Gil has
proposed w/o negatively impacting the above text.  So, this issue can
apply to all spec.
Comment 3 Robert Freund 2010-01-19 21:06:09 UTC
The term "generate" is used in relation to the various faults defined by this specification to imply that a fault is produced and no futher processing SHOULD be performed. In these cases the fault SHOULD be transmitted. However, there might be reasons when a compliant implementation can choose not to transmit the fault - for example, security concerns - in these situations the fault MAY NOT be transmitted.
Comment 4 Robert Freund 2010-03-17 11:30:26 UTC
resolved on 2010-01-19 with text in comment #3