[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i093 cardinality replacements
I understand the background. Now that we have identified the specific changes that are being made I question the necessity for this one. Most of the others that have been made that were explained on last week's call seem fine. This one I think we don't need to make. We have normative dependencies on other specs that describe elements this way so the reader will be familiar with the style. I think the current style is more readable and easier to understand than the other alternatives I see on the table right now. Frankly I can't think of a better way to say it either. Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/ -----Original Message----- From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] Sent: Wednesday, May 24, 2006 1:30 PM To: Marc Goodner Cc: Gilbert Pilz; ws-rx@lists.oasis-open.org Subject: Re: [ws-rx] i093 cardinality replacements The TC took a vote and decided to more correctly align with RFC 2119. That RFC is about implementations, not exchanged messages. Personifying elements and attributes is a Bad Idea[tm]. On 24/05/06 13:23, Marc Goodner wrote: > Why are we changing the text around these again? I'm sorry but I don't > find the current text confusing. As to saying that we can't say an > element is REQUIRED according to 2119 I can easily find precedent for > this language in W3C Recommendations. I don't think we need to do this. > > Marc Goodner > Technical Diplomat > Microsoft Corporation > Tel: (425) 703-1903 > Blog: http://spaces.msn.com/mrgoodner/ > > > -----Original Message----- > From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] > Sent: Thursday, May 18, 2006 5:02 PM > To: ws-rx@lists.oasis-open.org > Subject: [ws-rx] i093 cardinality replacements > > As of WD-12 our spec has a number of explanations of sub-elements with > the following pattern: > > /wsrm:Foo/wsrm:Baz > This [REQUIRED | OPTIONAL] element . . > > There are actually a number of different cases under which this > pattern is used. > > 1) Describing a singly-nested sub-element within a message element. > Example: /wsrm:CreateSequence/wsrm:AcksTo > > 2) Describing a singly-nested sub-element within a header element. > Example: /wsrm:AckRequested/wsrm:Identifier > > 3) Describing a doubly-nested sub-element within a top-level message > element when the parent element is optional. Example: > /wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier > > There are other cases like doubly-nested attributes within top-level > header elements who's parent elements are optional, etc. but you get > the point. > > > I have used the following patterns to address these cases: > > 1) The RM [Source | Destination] [MUST | MAY] include this element in > any Foo message it sends. > > (Note the use of the informal "Foo message" as shorthand for "SOAP > envelope that includes the <wsrm:Foo> element in the body of that > envelope") > > 2) An RM [Source | Destination] that includes a <wsrm:Foo> header > block in a SOAP envelope [MUST | MAY] include this element in that > header block. > > 3) An RM [Source | Destination] that includes a <wsrm:Baz> element > within a Foo message [MUST | MAY] include this element as a child of > the <wsrm:Baz> element. > > If anyone in the group has any suggestions on some better phrasing for > these patterns I would be more than happy to hear them. > > Also, with respect to the idea that the current cardinality statements > are somehow clear to the reader, take a second look at the example for > case (3): > > /wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier > This REQUIRED element MUST contain an absolute URI conformant with > RFC3986 [URI] that uniquely identifies the offered Sequence. > > What it *means* is that if you include an Offer in your CreateSequence > then you MUST include the Identifier in that Offer but all it *says* > is "This REQUIRED element . . ." This doesn't seem very clear to me at all. > > - gp > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]