[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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]