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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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


Actually for the 1) I think we should strip out all those MUST and MAY that just repeat what is in the schema. The fact that
something in schema says 0..1 doesn't require us to say anything normatively in the text aside from complying with the schema IMHO.

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: 10 March 2009 23:20
> To: Simon Nash
> Cc: 'OASIS SCA Assembly List'
> Subject: Re: [sca-assembly] NEW ISSUE: Incorrect usage of MAY Keyword
> 
> Simon Nash wrote:
> > 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.
> >
> 
> I agree that MAY here does not mean that it is optional for the *SCA
> Runtime*.
> 
> I think there are three cases here:
> 1) MAYs that indicate an optionality wrt document instances. Eg. an
> element that has cardinality of 0..1.
> 2) MAYs that talk about semantics (as Eric noted). I don't think we
> should be using a MAY for this.
> 3) MAYs that indicate an optionality wrt support by conformant SCA Runtimes.
> 
> For (1) and (3) as long as we use the right target we should be OK.
> ASM50018, ASM50021, and ASM90004 talk about the reference/wire targets.
> These are specific document elements/attribute. Therefore, I think they
> are correctly worded. It is optional for a document instance to use a
> specific wire target syntax or specify a target for references with
> cardinality 0..1, 0..n etc.
> 
> If we want to clearly distinguish case (1) and (3) above, we should
> either provide some additional markup that clearly identifies the target
> or in appendix C add a new column called 'target' (Martin had put
> forward this idea some time back), or both. For example, WS-I profiles
> requirements contain targets in all CAPS. They also define the targets
> right at the beginning of the profiles.
> 
> -Anish
> --
> >   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
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]