[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
Martin Chapman wrote: > 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. > I think there is a problem here. I went through all the conformance statements that use MAY, and a number of them don't fall into the category of things for which it would be permissible for vendors to omit support. Examples of this include ASM50018, ASM50021 and ASM90004. Simon > 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 > > > > --------------------------------------------------------------------- > 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]