RE: [opencsa-liaison] Action Item #0001 Submit an issue on 'DefineConformance Targets'

[Bryan Aupperle <aupperle@us.ibm.com>]

+1

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Master Inventor

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

"Michael Rowley" <mrowley@bea.com>

11/14/2007 04:34 AM

To	<ashok.malhotra@oracle.com>, <sanjay.patil@sap.com>, <opencsa-liaison@lists.oasis-open.org>
cc
Subject	RE: [opencsa-liaison] Action Item #0001 Submit an issue on 'Define Conformance Targets'

Are we allowed to have emails about this before it has an issue number?

I'll risk it.

I like the first two items in the proposal, although I'm doubtful about
the third.  I suspect that in most cases, the error will be displayed
to
the user.  How a tool displays, what is essentially a compile-time
error, will vary greatly from tool to tool.  Some tools will underline
the offending SCDL with a red squiggly line.  I don't think this should
be disallowed?

I think standardizing on errors would primarily make sense if we were
standardizing on APIs for the various tools that would check for these
errors, but I don't think we are.

Michael

-----Original Message-----
From: ashok malhotra [mailto:ashok.malhotra@oracle.com] 
Sent: Monday, November 12, 2007 3:55 PM
To: sanjay.patil@sap.com; opencsa-liaison@lists.oasis-open.org
Subject: [opencsa-liaison] Action Item #0001 Submit an issue on 'Define
Conformance Targets'

TARGET: Open-SCA Liaison

DESCRIPTION :  On or about Nov 6, Martin Chapman sent a message to
the 6

SCA TCs with the following content:

TARGET: SCA Policy Specification 

DESCRIPTION: In order to write a normative statement or conformance
clause using RFC2119 language, the target or subject of the rule
needs to be included. Some of these are obvious, as we have rules
governing components, composites, services, references etc. Other
targets are less so, especially when it comes to conformance, as we need
to identify artefacts that vendors can claim they handle
according to the rules of the spec. We should enumerate a list of
conformance targets early on, so that every time we use a MUST,
MAY, or SHOULD, we know to what the rule applies to.


PROPOSAL: 

It took me a while to figure out exactly what we needed to do about
this.  After speaking with Martin,
here is what each of the TC needs to do to its specifications.

1. Reword the specifications using RFC 2119 keywords.
2. For each appearance of MUST or MUST NOT, specify the component that
should check whether the statement is obeyed.  This is the conformance
target.  It may be the SCDL processor, for example, or it may be more
specific (better) for example, the wire compatibility checker.
3. Specify the error that MUST be raised if the statement is not
followed.



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php