Our job is to write the rules
for what constitutes valid sca bpel, as constrained by the Assembly
rules.
Our job is necessarily more than that. Our job also includes writing
rules that define the transformation between (SCA)BPEL and the
introspected component types, no matter how hard that notion is for
Assembly to formalize. I don't understand how we can avoid writing
these rules with some formality. It's a bit of a dodge to say that a
runtime isn't conformant (Assembly) because it didn't follow our rules
(BPEL), but I understand that dodge.
I would certainly agree that if
we define rules we use RFC2119, but in this case the rules are not
defined in our spec.
I point back to your proposal, point 3:
In the bpel spec we should
define what the introspected CT/default
rules are.
It is these rules that I was talking about writing using some
well-understood language, maybe 2119. What should that language look
like?
Martin Chapman wrote:
008401c91858$01da9260$4554908d@ie.oracle.com"
type="cite">
The point I was trying to convey is that SCA
Assembly defines the rules of CT files. Each c+i is constrained by
these rules, but these rules do not have to be defined in each c+i.
I would certainly agree that if we define rules
we use RFC2119, but in this case the rules are not defined in our spec.
Either you have a valid sca bpel description, or you don't; if you do
have one you will have a valid introspected CT file if you want one.
Our job is to write the rules for what constitutes valid sca bpel, as
constrained by the Assembly rules.
Martin.
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:
00c301c9141d$2dfb2290$0c40908d@ie.oracle.com"
type="cite">
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
|