[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] REOPEN ISSUES 132 and 149: Update to Sanjay's Proposal
hi, some comments/agreements/disagreements below; On Apr 26, 2010, at 9:56 AM, Eric Johnson wrote: > In principle, I'm not against the notion of making SCA work for > other implementation types. In practice, I'm not sure that the > revised proposal gets us there. > > Procedural question - what is the threshold for reopening closed > issues? Am I correct in thinking it is 2/3rds of all voting members > (not just the quorum)? I could track it down, but I suspect someone > can answer quickly. > > Although the issue hasn't been opened yet, comments follow. > > On 04/23/2010 05:33 PM, Estefan, Jeff A (3100) wrote: >> >> Raiser: Jeff A. Estefan / Mike Edwards >> >> Target: SCA Assembly Model Specification Version 1.1 >> >> Description: Update to Sanjay’s Proposal in Response to Issues 132 >> and 149 >> >> Proposal: The following is a recommended update to Sanjay’s >> original proposal to address Issues 132 (http://www.osoa.org/jira/browse/ASSEMBLY-132 >> ) and 149 (http://www.osoa.org/jira/browse/ASSEMBLY-149) by >> replacing the current text of Section 13.2 (SCA Runtime) in the SCA >> Assembly Model Spec with the language provided below. The original >> text of Sanjay’s proposal is included as well as the inline updates >> showing recommended updates. Note that this proposal also comes >> with the accompanying documentation attached. Justification for >> reopening these issues is articulated in the Justification section >> that follows the proposal. >> >> Revised Sanjay Proposal: >> An implementation that claims to conform to the requirements of an >> SCA Runtime defined in this specification MUST meet the following >> conditions: >> >> 1. The implementation MUST comply with all statements in >> Appendix C: Conformance Items related to an SCA Runtime, notably >> all MUST statements have to be implemented. >> >> 2. The implementation MUST conform to the SCA Policy Framework >> v1.1 Specification [Policy]. >> >> 3. The implementation MUST support at least one implementation >> type standardized by the OpenCSA Member Section or comply with the >> following rules for at least one of the other implementation types: >> >> a. The implementation type is defined in compliance with the >> SCA Assembly Extension Model (Section 10 9 of the this SCA Assembly >> Specification). >> >> b. A document describing the mapping of the constructs defined >> in the SCA Assembly specification with those of the implementation >> type is made publicly available to its prospective development >> community. >> > > Under what license? Many companies still include absurdly onerous > licensing terms on their software. I can imagine a license on an > SCA document of this sort that simply disallows any public > discussion of the quality of the SCA implementation/conformance, or > of the document in question. Consequently, this document, once it > exists, may simply be of no use to anyone who receives it, because > they may not be able to discuss it with anyone. OASIS does not, and cannot, specify the business practices (e.g. licenses that company choose to use for their products). NOTE: The IPR Policy only talks about what licenses obligated members are required to grant for their Essential Claims, it is NOT about products. On the substance - I have no idea what "publicall available means" and besides which -- What is to stop me from producing a document which says only: "My product does some really cool mappings" While absurd, this meets the requirement - and since no standards body is involved, there is no one who can OFFICIALLY make that determination. > > My take is that anyone claiming conformance must be willing to share > their specification of how they conform with as wide an audience as > possible, so that it can be subject to the broadest scrutiny. This > doesn't need to imply any sort of license to the underlying > technologies, just the freedom to copy the specification. In > addition, should an SCA provider come up with a useful way to > specify conformance, the SCA community could benefit from being able > to see that alternate approach. nice sentiments and I agree with them. BUT, again, none of this is enforceable. > > I've argued before, and I'm arguing again we could mandate one of > any number of useful licenses for accommodating these needs. Some > Creative Commons license (Creative Commons Attribution?) might be > sufficient. OASIS can't mandate anything of the sort. > >> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]