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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: Re: [sca-assembly] NEW ISSUE: (v1.1) Upgrade ASM12017, ASM12030,ASM14004 be mandatory statements


Hi Martin,

I raise the points, because I think the issue is incorrect.

In the case of ASM12030, the normative statement appears to be about the 
contents of a value of an attribute provided by a user of the SCA specs, 
at least the way I read it. Which makes the normative target a person. 
Perhaps I'm mis-reading the normative statement? In any case, if the 
target is a person, then it shouldn't be a normative statement.

As for ASM14004, if you're defining "static analysis" with "i.e." in the 
definition, then I'm happy with the darn thing being turned completely 
non-normative, not the reverse - a mandatory normative item - as 
proposed in the issue.

On 3/14/11 10:13 AM, Martin Chapman wrote:
> Responses below, but your questions are valid even if the issue opens or not;-)
>
>
>> -----Original Message-----
>> From: Eric Johnson [mailto:eric@tibco.com]
>> Sent: 14 March 2011 16:32
>> To: Martin Chapman
>> Cc: OASIS Assembly
>> Subject: Re: [sca-assembly] NEW ISSUE: (v1.1) Upgrade ASM12017, ASM12030,
>> ASM14004 be mandatory statements
>>
>> I hesitate to comment on the the substance of the proposal, since this
>> hasn't been logged yet, but:
>>
>> What's the normative target of ASM12030?
> A scdl document
>> For ASM14004, what's the definition of static analysis?
> schema plus additional constraints defined in the spec i.e. that schema doesn't capture.
>
>> -Eric.
>>
>> On 3/14/11 8:23 AM, Martin Chapman wrote:
>>> Target: SCA Assembly v1.1 Specification (and Test assertion/cases)
>>>
>>> Description: During review of the specification three normative statements
>> would increase portability/interoperability of SCA Runtimes by being made
>> mandatory. The statements affected are ASM12017, ASM12030, ASM14004.
>>> Proposal:
>>>
>>> ASM12017:
>>>
>>> Change: "[ASM12017] Where a component that is the target of a wire is
>> removed, without the wire being changed, then future invocations of the
>> reference that use that wire SHOULD fail with a ServiceUnavailable
>> fault...."
>>> To: "[ASM12017] Where a component that is the target of a wire is removed,
>> without the wire being changed, then future invocations of the reference
>> that use that wire MUST fail with a ServiceUnavailable fault...."
>>> ASM12030:
>>>
>>> Change: "[ASM12030] For XML definitions, which are identified by QNames,
>> the @namespace attribute of the export element SHOULD be the namespace URI
>> for the exported definitions."
>>> To: "[ASM12030] For XML definitions, which are identified by QNames, the
>> @namespace attribute of the export element MUST be the namespace URI for the
>> exported definitions."
>>> ASM14004:
>>>
>>> Change: "[ASM14004] When an error that could have been detected through
>> static analysis is detected and raised at runtime for a component, the
>> component SHOULD NOT be run until the error is fixed."
>>> To: "[ASM14004] When an error that could have been detected through static
>> analysis is detected and raised at runtime for a component, the component
>> MUST NOT be run until the error is fixed."
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>


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