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

[Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM>]

> -----Original Message-----
> From: Eric Johnson [mailto:eric@tibco.com]
> Sent: 14 March 2011 18:03
> To: Martin Chapman
> Cc: OASIS Assembly
> 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.

Not really, the target is the scdl document and what makes the scdl valid or not. I have no idea if it's a person or a tool producing the scdl but the rules of what a correct scdl must look like needs to be defined.

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

We all know that schema is not expressive enough and that additional constraints may need to be defined. The static analysis refers to schema plus the other rules documented in the spec. It's the same model as used in many specs including ws-bpel. Some of us had a discussion about formalizing these addition rules in something like schematron but decided against it.

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