[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword
Eric, I don't see our usage as inconsistent, and is used this way in a number if OASIS (and non-OASIS specs). IETF predominantly defines protocols and as a vendor of a protocol optionality of support and optionality of semantics pretty much equate to the same thing IMHO. I think your other issue about what we say in the conformance regarding optional items is much more relevant. Martin. > -----Original Message----- > From: Eric Wells [mailto:eric.wells@hitachisoftware.com] > Sent: 07 March 2009 13:31 > To: OASIS SCA Assembly List > Subject: [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword > > All, > I think that in several places in the specification the usage of the > keyword MAY is not consistent with the definition in RFC2119. To quote > http://www.ietf.org/rfc/rfc2119.txt: > > 5. MAY This word, or the adjective "OPTIONAL", means that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > > In several places MAY is used to indicate the semantics of an artifact and > NOT that a behavior is optional. I believe other usage of MAY (and SHOULD) > are consistent with the RFC2119 definition. > > Note I DO NOT want to delay the CD03 vote, so it may be more appropriate to > handle these issues on the public comment list. However I will defer to > others as to how best to handle these items. > > Best Regards, > Eric. > > Eric Wells. > Consulting Engineer. > Hitachi Computer Products (America) Inc. > San Francisco, CA. USA. > +1 (415) 656-4346 > eric.wells@hitachisoftware.com > > > Based on the CD03 Word document at: > > > http://www.oasis-open.org/committees/download.php/31566/sca-assembly-1.1-spe > c-cd03.doc > > I think that the following normative statements need corrections: > > Unmarked normative statement Lines 836 - 840 > ============================================ > "If the component reference has @nonOverridable==false and @multiplicity > 1..1 and the reference has a target, then any composite reference which > promotes the component reference has @multiplicity 0..1.by default and MAY > have an explicit @multiplicity of either 0..1 or 1..1." > > Although this is not marked as a normative statement, I think the use of the > MAY keyword is probably correct and either value for @multiplicity is > arbitrarily allowed. > > PROPOSAL: > Add a normative reference for the statement. N.B. If a vendor should NOT be > allowed to arbitrarily choose the value for @multiplicity the statement > should be reworded. (Note there is an extra period in "0..1.by" that should > be corrected editorially regardless of this issue). > > > > ASM50016 Lines 910 - 914 > ======================== > "It is possible that a particular binding type MAY require that the address > of a target service uses more than a simple URI. In cases where a reference > element has a binding sub element of such a type, the @uri attribute of the > binding element MUST NOT be used to identify the target service - instead, > binding specific attributes and/or child elements MUST be used. [ASM50016]" > > I believe the intent is to say some bindings DO IN FACT require more than a > simple URI - it isn't (in general) optional for that particular binding > type. > > Also, the phrase "MAY require" semi-confuses two RFC2119 keywords. This may > be a little pedantic as I think it is clear what is being stated. However, > it would clarify matters to reword the statement. > > PROPOSAL: > I suggest making the first sentence of ASM50016 non-normative with (e.g.) > the following wording: > > "It is possible that a particular binding type will use more than a simple > URI for the address of a target service. In cases where a reference element > has a binding sub element that uses more than a simple URI, the @uri > attribute of the binding element MUST NOT be used to identify the target > service - in this case binding specific attributes and/or child elements > MUST be used. [ASM50016]" > > We should probably also say what constitutes a "simple URI". (I think this > is covered in section 8, Bindings, but there is no context for this > statement). > > It may also be more appropriate to place this requirement in section 8 - > Bindings. > > > > ASM50018 Line 921 > ================= > "A reference with multiplicity 0..1 or 0..n MAY have no target service > defined. [ASM50018]" > > Again, this statement is not really specifying optional behavior - it is > making a statement about the semantics of the @multiplicity attribute. I.E. > If there are no target services defined the "actual configured multiplicity" > is zero (which is consistent with 0..1 and 0..n). > > PROPOSAL: > I suggest making [ASM50018] non-normative to "remind" readers that for 0..1, > 0..n it is possible that no target services are configured. > > > > ASM50021 Lines 926 - 927 > ======================== > "A reference with multiplicity 0..n or 1..n MAY have one or more target > services defined. [ASM50021]" > > The same considerations as for ASM50018, above, apply. > > PROPOSAL: > I suggest making [ASM50021] non-normative. > > > > ASM70005 Lines 2369 - 2373 > ========================== > "An implementation MAY contain additional services, additional references > with @multiplicity=0..1 or @multiplicity=0..n and additional properties with > @mustSupply=false beyond those declared in the constraining type, but MUST > NOT contain additional references with @multiplicity=1..1 or > @multiplicity=1..n or additional properties with @mustSupply=true > [ASM70005]" > > I think this is the same situation as ASM50021. If so the first sentence > needs to be non-normative. > > PROPOSAL: > Reword ASM70005 as follows: > > "It is possible that an implementation contains additional services, > additional references with @multiplicity=0..1 or @multiplicity=0..n and > additional properties with @mustSupply=false beyond those declared in the > constraining type. However, an implementation MUST NOT contain additional > references with @multiplicity=1..1 or @multiplicity=1..n or additional > properties with @mustSupply=true [ASM70005]" > > > > ASM90004 Lines 2786 - 2787 > ========================== > "To do so, a wire target MAY be specified with a syntax of > "componentName/serviceName/bindingName". [ASM90004]" > > This usage could be correct, but NOT if we are saying that this syntax MUST > be used to wire to a specific binding. Again, is this an optional feature > that vendors can choose to implement or not? > > PROPOSAL: > If this syntax is obligatory to wire to a specific service we should change > the wording to: > > "To wire to a specific binding of a component service the syntax > "componentName/serviceName/bindingName" MUST be used. > > > > Unmarked normative statement Lines 3434 - 3436 > ============================================== > "n the sca-contribution.xml file, additional elements MAY exist that list > the namespaces of constructs that are needed by the contribution and which > are be found elsewhere, for example in other contributions." > > This appears to be a bad edit. > > PROPOSAL: > Remove lines 3434 - 3436 or correct text and mark the statement as > normative. > > > > ASM12013 Lines 3750 - 3761 > ========================== > "For components at the Domain level, with References for which > @autowire="true" applies, the behavior of the SCA runtime for a given Domain > MUST take ONE of the 3 following forms: > 1) The SCA runtime MAY disallow deployment of any components with autowire > References. > In this case, the SCA runtime MUST raise an exception at the point > where the component > is deployed. > 2) The SCA runtime MAY evaluate the target(s) for the reference at the > time that the > component is deployed and not update those targets when later > deployment actions occur. > 3) The SCA runtime MAY re-evaluate the target(s) for the reference > dynamically as later > deployment actions occur resulting in updated reference targets which > match the new > Domain configuration. How the new configuration of the reference takes > place is > described by the relevant client and implementation specifications. > > I do not think we should mix the mandatory MUST in the first sentence with > the optional MAY in the numbered clauses. (This would allow a vendor to > choose say, option 1, and then, because it is optional, choosing not to > disallow deployment. > > PROPOSAL: > I suggest the following wording: > > "For components at the Domain level, with References for which > @autowire="true" applies, the behavior of the SCA runtime for a given Domain > MUST take ONE of the 3 following forms: > 1) The SCA runtime disallows deployment of any components with autowire > References. > In this case, the SCA runtime MUST raise an exception at the point > where the component > is deployed. > 2) The SCA runtime evaluates the target(s) for the reference at the time > that the > component is deployed and does not update those targets when later > deployment actions > occur. > 3) The SCA runtime evaluates the target(s) for the reference dynamically > for each > deployment action, resulting in updated reference targets which match > the new > Domain configuration. How the new configuration of the reference takes > place is > described by the relevant client and implementation specifications." > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]