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
|