OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

opencsa-liaison message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


-----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.


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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]