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

+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: 

"Michael Rowley"
<> 

11/14/2007 04:34 AM

To

<>, <>,
<>

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:] 

Sent: Monday, November 12, 2007 3:55 PM

To: ; 

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