[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] Action item: SCA BPEL conformance statements and componentType
Danny, You have a very valid point. AISI, But this particular case is tricky. The RFC 2119 keywords need to have a conformance target. Without a target, I'm not sure if it is any different than regular explanatory text. To be testable a conformance target needs to be something that is tangible. For example, The WIDGET MUST be square in shape. The problem here is that the generated CT is not something that is testable or can be pointed to. It's effects, as they apply to the runtime, are testable. In that sense, what we are stating is really its definition. I think we can do one of two things: 1) In assembly, create a conformance target called 'INTROSPECTED CT' (or something like that) use 2119 keywords in our algorithm for introspection. And explicitly call out that an 'INTROSPECTED CT' is not testable and we won't create any tests specifically for this target. 2) We can always use notations/formats that make a clear distinction between explanatory text and definitions. There are several examples out there for this. Some use indentation/italics to highlight definitions along with tagging it as such. Others use pseudo-code or very clear algorithmic language to specify things like this (along with a special typographic convention). I think we could do either. -Anish -- Danny van der Rijn wrote: > I mostly like this proposal. But I can't let it go by without trying to > change it :-) > > A comment on your point 3. You say: > > " The bpel spec or any other impl spec will not contain conformance > statements wrt CT, only rules/assertions." > > One of the benefits of using RFC 2119 language is that it clearly spells > out the difference between explanatory text; text that lays out required > implementation rules; and text that lays out optional implementation > rules. If we don't use RFC 2119 in describing the "introspected CT > rules" then we need to come up with other language making that > distinction. This could come in many forms, but it needs to be > intuitive, and the same across all C&Is. There's already one such form, > and it's RFC 2119. Personally, I think it's a lot easier to use what's > there. > > > Martin Chapman wrote: >> >> Myself and Anish had a chat about conformance targets and component >> types. Here's a summary and >> conclusion. >> >> Martin. >> ----- >> >> WRT component type (CT) there are three cases: >> >> 1) There is no CT side file and there aren't any SCA extensions in the >> BPEL process >> 2) There is no CT side file and there are SCA extensions in the BPEL >> process >> 3) There is a CT side file. >> >> In case (1), the default rules that we define for the introspected CT >> kick in. The introspected CT is the effective CT. >> In case (2), the default rules in conjunction with our extension rules >> specify what the effective CT will be. >> In case (3), the introspected CT is merged/overridden with/by the side >> file to provide the effective CT. >> >> SCA has the following as conformance targets (relevant to issue 18): >> >> a) component type side files >> b) composite files >> c) SCA runtime >> >> We think we should restrict the conformance statements to these targets >> and not create new conformance targets that aren't physical artifacts >> that you can point to. >> >> We would like to propose that >> >> 1) In the assembly spec we define a term 'effective CT' (or something >> like that -- the name isn't important). There is already issue 36 [1] >> filed in Assembly TC that is meant to address how the CT side file >> relates to introspection (subset/override) and essentially what the >> 'effective CT' will be. In addressing that issue we can define precisely >> how the effective CT is calculated from the side file and the >> introspected CT, and we can complete the conformance statements >> about the relationships between the conformance targets (comonent type >> side files, >> composite file, and implementations) >> >> 2) In the assembly spec, we should have conformance statements that >> applies to the SCA runtime which say what the runtime MUST/MUST NOT do >> given an effective CT. >> For example, it would talk about the fact that all services that are >> part of the effective CT must be enabled/deployed/made available by the >> runtime. >> >> 3) In the bpel spec we should define what the introspected CT/default >> rules are. These would be definition/rules. Not conformance statements. >> The bpel spec or any other impl spec will not contain conformance >> statements wrt CT, only rules/assertions. >> >> 4) In the bpel spec we should have conformance statement about the BPEL >> process. For example: Both sca:service and sca:reference attributes MUST >> NOT be present on the same partnerlink in a SCA BPEL process. >> These are the rules to produce a valid introspected CT; violate these >> rules in your source, >> and you have an non-compliant source. >> >> In effect, the implementation specs specify (i) rules for introspection >> and extensions and (ii) conformance statements that apply to >> implementation sources (such as BPEL process). And assembly spec >> specifies (i) how effective CT is calculated and (ii) conformance >> statements on SCA runtime wrt what it does with the effecttive CT. >> >> >> [1] http://www.osoa.org/jira/browse/ASSEMBLY-36 >> >> >> --------------------------------------------------------------------- >> 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]