NEW ISSUE: Incorrect usage of MAY Keyword

["Eric Wells" <eric.wells@hitachisoftware.com>]

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."