AW: [sca-assembly] ISSUE 6: usage of not promoted references

[MR: inline]

-----Original Message-----
From: Peshev, Peter [mailto:peter.peshev@sap.com]
Sent: Wednesday, October 24, 2007 3:26 AM
To: Michael Rowley; OASIS Assembly
Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references

HI Michael,

Comments inline, I have pasted your issues with ">"

>- First, "RECOMMENDED" and "NOT REQUIRED" are not a defined keywords.

PP : There is no ""RECOMMENDED" in this proposal. In addition when

looking at http://www.ietf.org/rfc/rfc2119.txt RECOMMENDED and REQUIRED

are mentioned as key words.

[MR: Good point on RECOMMENDED (I had originally written just “NOT REQUIRED”, but then belatedly (and incorrectly) added “RECOMMENDED” when I happened to see it – apparently when I was looking too far down in the email to the old proposal). Regarding “NOT REQUIRED” – yes “REQUIRED” is a keyword, and “MUST NOT” is also a key phrase, but “NOT REQUIRED” is not.]

Anyway as per the notes of the OpenCSA

Steering Committee Minutes from 28 September the keyword SHOULD and

its synonym RECOMMENDED are supposed to be avoided, and only the rest of

the keywords remain to be used. However being a developer I don't claim

any competence in speac creation, so maybe you are right.

> In particular, the bit that says that "an implementation which does

not include a particular option MUST be prepared to interoperate with

...". What does that mean when the "implementation" is the assembler?

PP : At least my understanding of the keyword usage is that they should

be used whenever there is requirement towards the SCA Runtime (i.e. the

vendors that will implement the spec), and not to be used for any users

of the spec -- assembler, deployer, etc. That's what was supposed to be

in the proposal, If something is not done in that way, I will be glad to

fix.

if the first sentence is not clear enough, maybe we can adapt it to :

Promotion of references accessing endpoints via bindings is common

practice since it allows the assembler to change the targets of the

references or the specified bindings and encourages component reuse,

however the lack of such promotion MUST NOT cause error in SCA Runtime-s

[MR: I think it is worthwhile to say that promotion is recommended (lowercase). I think it is very valuable for the specification to include directives and suggestions to our various human roles. Changing the MUST NOT to be on the runtime seems better, but perhaps it should be on deployment, as in “lack of promotion MUST NOT cause an error during deployment.”]

>- I suspect that we should not REQUIRE that a deployment error be

generated for unwired 1..1 references. Consider what would happen if

someone developed deployable composites A and B (each from different

contributions) with the intention of wiring at least one of the

components from A to something in B and wiring at least one component in

B to something in A. There would be no legal ordering of the

deployments, as the first deployment would always fail.

PP : Yes, it will be an error. In that case the assembler should use

0..1 if he wants to deploy the first component and after some time the

other. Isn't this exactly what 0..1 was intended for ? Otherwise what is

the difference between 0..1 and 1..1 ?

[MR: Having 1..1 instead of 0..1 could mean that an error should be generated at runtime, possibly at the first use of the component that includes that reference, rather than at deployment time. It would be unfortunate for someone to have to declare a reference that is really required as 0..1 just to get around deployment order issues.]

>- The last MUST, which is on the programming model, says: "MUST

represent the reference's wiring state in accordance to the

implementation type in question". Presumably Peter meant to include the

words "as invalid" after the word "state". However, even with this

modification I don't like the requirement. SCA is intended to be an

integration technology, which means that it needs to be able to

accommodate a wide variety of implementation types. Some of these

implementation types will use programming models where external services

can be used, but some kind of default behavior occurs if one isn't

(think of extensibility hooks). Such a programming model should be able

to represent these as references to SCA, in spite of the fact that they

don't follow the admonition that unwired references be presented as

nulls.

PP : The wording "according to the implementation type in question" was

supposed to cover the "wide variety of implementation types" that you

are speaking. If you prefer some other wording I would be glad to

include. Maybe mentioning explicitly extensibility hooks if you

consider them so important :

... MUST NOT generate deployment errors and MUST represent the

reference's wiring state in accordance to the implementation type in

question (e.g. null,

handle that throws exceptions when accessed, extensibility hooks, etc.).

[MR: I was reacting against this on the assumption, apparently incorrect, that the words “as invalid” had been removed accidentally, since the current sentence doesn’t seem to make any sense. I read the current wording as saying “the programming model MUST represent the reference however it wants.” What kind of a requirement is that?]

Michael

Best Regards

Peter

________________________________

From: Michael Rowley [mailto:mrowley@bea.com]

Sent: Tuesday, 23. October 2007 20:54

To: Peshev, Peter; OASIS Assembly

Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references

I'll comment on the RFC 2119 usage, which I had hoped to avoid, but I we

have to address it at some point, so we might as well start with this

proposal.

- First, "RECOMMENDED" and "NOT REQUIRED" are not a defined keywords.

If we changed it to use the closest defined keyword ("MAY") it might be

something like "The assembler MAY promote references...", but that would

be odd, given the definition of MAY according to 2119:

5. MAY This word, or the adjective "OPTIONAL", mean 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.

An implementation which does not include a particular option MUST be

prepared to interoperate with another implementation which does

include the option, though perhaps with reduced functionality. In the

same vein an implementation which does include a particular option

MUST be prepared to interoperate with another implementation which

does not include the option (except, of course, for the feature the

option provides.)

In particular, the bit that says that "an implementation which does not

include a particular option MUST be prepared to interoperate with ...".

What does that mean when the "implementation" is the assembler?