RE: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay'sProposal

[Martin Chapman <MARTIN.CHAPMAN@oracle.com>]

One of the arguments put forward when we discussed this at the December F2F, where we closed no action, was that it doesn't make sense without some definition of what a compliant language mapping must/should etc contain. At that time no proposal existed and it was decided not to hold up 1.1.
 
Two working drafts have now been proposed which begin to address this, though I think a bindings one might be needed in addition. IMHO, if we re-open this issue, it should be with the assumption that the necessary documents are progressed to CS/OS at the same time as the Assembly specification, including RFC2119, 60 day reviews etc, and that we  revisit relevant conformance sections and cross check that each of the OpenCSA language mappings and bindings comply with these new specifications.

Cheers,
  Martin.


> >> Such a document should help in understanding how SCA components can
> >> be developed using the implementation type, how these components
> >> can be configured and assembled together (as instances of
> >> Components in SCA compositions). A template for such a document
> >> entitled "Implementation Type Documentation Requirements for SCA
> >> Assembly Model Version 1.1 Specification" has been provided by this
> >> Technical Committee.  The contents outlined in this document
> >> template MUST be completed in order for an implementation type to
> >> claim compliance with the SCA Assembly Specification. To get an
> >> idea about the purpose and scope of such a document that describes
> >> the implementation type, see the Client and Implementation
> >> specifications for the implementation types standardized by the
> >> OpenCSA Member section.
> >>
> >
> > The "Implementation Type Documentation Requirements ..." document
> > sounds useful.  Absent that document, I don't see a point to opening
> > the issue, as this document is at the heart of whether or not we can
> > define our way out of this box.  I've long thought that the Assembly
> > TC should actually formally define what it means to be a valid
> > implementation or binding specification, so that we'd have a list of
> > criteria that all the specs could satisfy.  I'd want to see such a
> > document before addressing the question of reopening the closed
> > issues.
> 
> I agree. --- when someone gets around to writing it, it would be very
> useful
> >
> > Question - once we have this document, don't we have to go back
> > through and validate that the existing specs satisfy the criteria?
> 
> yes
> >
> >> c.      An adapted version of the SCA Assembly Test Suite for
> >> testing the implementation type is created and is made
> >> publiclyavailable to its prospective development community.
> >>
> > Again, my concerns about the narrow focus.
> >
> >> A template for such a document entitled "Test Suite Adaptation for
> >> SCA Assembly Model Version 1.1 Specification" has been provided by
> >> this Technical Committee.  The contents outlined in this document
> >> template MUST be completed in order for an implementation type to
> >> claim compliance with the SCA Assembly Specification.
> >>
> >
> > Again, this document would be useful, independent of this issue, but
> > absent it, I don't see a point to reopening the closed issues.
> 
> +1
> 
> cheers,
>    jeff m
> >
> >> 4.      The implementation MUST support one or more binding types.
> >> If only one binding type is supported, it MUST be the default SCA
> >> binding type, binding.sca.
> >>
> >
> > Question: why wouldn't we extend the notion of conforming alternate
> > implementation types extended to alternate binding types?
> >
> >> Justification:  The SCA assembly model should be made agnostic to
> >> specific implementation technology to the maximum extent possible
> >> so that it may be used as THE industry standard model for component
> >> and composite assembly.  Not all implementation technologies are
> >> "open," "standards-based," and/or "non-proprietary."  It's simply
> >> not realistic.
> >
> > This argument confuses the patents and copyrights covering the
> > underlying technology with the license that covers a specification
> > how that technology works with SCA.  I agree with Jeff that this
> > proposal is trying to have it both ways.
> >
> >
> >
> >
> >>   If the TC has a moral objection to such solutions, then that is a
> >> personal bias and it should be clearly stated at the beginning of
> >> each SCA-* specification.
> >
> > I find the inclusion of this statement inappropriate.  Are moral
> > issues ever just "personal"?  And it is quite odd to consider that
> > the will of the TC could be misconstrued as "personal" as well.  And
> > finally, the "moral" stance of the TC is, in fact, stated at the
> > beginning of each specification, in the form of the legal framework
> > surrounding the specs.
> >
> > This also misconstrues the problem.  If we were even contemplating
> > the question, it isn't a moral one, so much as an ethical one.  Does
> > a company "X", selling a product "Z", get to claim "Y", but not have
> > to show anyone but their customers (not even their prospective
> > customers, mind you) how they can validly claim "Y"?
> >
> > ----
> >
> > Since the proposal above is premised on the addition of two new
> > documents to the suite of SCA, is this scope of work more
> > appropriate for SCA 1.2?
> >
> > -Eric.
> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> 
> --
> Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
> Sr. Director, Oracle Fusion Middleware 				+1(650)506-1975
> 	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
> Oracle								Redwood Shores, CA 94065
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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
>