[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 124 proposal version 2
On 3/24/2010 10:59 PM, Eric Johnson wrote: > Hi Anish, > > On 03/24/2010 02:51 PM, Anish Karmarkar wrote: >> Version 2 based on feedback from last week's call is attached. >> >> * Fixed editorial bugs pointed out by EricJ in section 6. >> >> * I did some due diligence on the question of whether creating >> independent conformance points for WSCB service/client results in a >> problem (as pointed out by EricJ), since the other non-section5 >> conformance items are no longer applicable to WSCB service/client. I >> found 5 assertions that are somewhat related (noted below). The others >> are about binding.ws syntactic elements/attributes or something similar. > > Thanks for spending the time to do that. I've been hoping to find the > time to get to that all week, and didn't, so I'm glad you did. > >> >> a) there is MUST for SOAP 1.1 and a SHOULD for SOAP 1.2. Section 5 >> also talks in several places about SOAP header blocks. Strictly >> speaking there is no necessity to require SOAP (1.1 or 1.2) for this >> protocol. It could depend only on WS-Addressing. But that is a >> separate issue. To fix this, I have changed the intro to 5.1 to state >> that this is a soap/ws-addressing based protocol. I didn't see a >> reason to introduce assertions for requiring SOAP/WS-A. It is required >> by definition. But if ppl feel strongly we can introduce new >> conformance items. > > Seems sort of ironic, though, if we define this stand-alone protocol, > and then it is possible to implement it in a way that is conformant, and > yet not compatible with an SCA runtime. Seems to me that we should > require the equivalent level of SOAP support, and therefore have the > MUST and SHOULD requirements around SOAP. > I don't believe this is appropriate. The protocol elements can't have both MUST and SHOULD. For a runtime that is fine, but I don't see why a WSCB service/client needs to necessarily support/allow both. If anything, we can say that the WSCB service/client MUST use either 1.1 or 1.2. > Maybe this is an equivalent nit, but we should likewise require support > for HTTP & HTTPS. > > BWS50010 is sort of tricky. In the context of SCA, if someone uses the > @wsdlElement form, then they'd be forced to support the WS-Policy spec, > as well as this requirement to recognize this policy assertion when it > appears in WSDL. Yet if we step away from that, to this stand-alone > definition, what's the conformance target for saying "if your WSCB > supports WSDL, then you must support this policy assertion?" > The policy assertion is for a particular endpoint or a WSDL binding (either it is embedded in WSDL or uses ws-mex). But this is independent of this issue. > Likewise for BWS50013 & 50014. >> >> >> b) There is a requirement for conforming to SCA assembly and policy. I >> don't think this is needed (it would defeat the purpose of the issue >> itself). >> >> c) There is a SHOULD for http endpoints to provide a wsdl description >> when queried with ?wsdl and a SHOULD for non http endpoints to provide >> some way to obtain the WSDL descriptions. I didn't see a need to have >> this requirement on WSCB service/client endpoints. I see this as a SCA >> runtime requirement not a protocol requirement. >> >> * wrt Dave's comment about BWS5005/7, I'm not sure what needs to >> change. I added a sentence at the beginning of section 5.1 that says >> that WSCB service implements the forward interface and the WSCB client >> implements the callback interface. >> >> Comments? > > Miscellaneous nit - Sections 6.2 & 6.3 reference Appendix B for > "Conformance items related to WSCB...", but that shows up as Appendix C. > Didn't I already say that I don't know my alphabet ;-) > And in section C, I don't see that you've separated out the conformance > requirements for WSCB client and server into a separate section. > I'm not sure we need to. But this applies to pre-issue124 spec as well. > Two minor editorial nits that I noticed, which Anish's proposal didn't > change, per-se: > "There are four categories of artifacts for which... SCA WS Binding XML > Document ... SCA Runtime" > > Shouldn't this be (to match the plural form): > "There are four categories of artifacts for which... SCA WS Binding XML > Documents ... SCA Runtimes" > Not sure if this is needed. We are talking about categories. > I also don't like the use of "artifact" here, because I associate the > word with something less operational than an "SCA Runtime". Can't we > just use the phrase: > "This specification defines four targets for conformance:" > Fine with me. > -Eric > >> >> -Anish >> -- >> >> On 3/18/2010 9:01 AM, Anish Karmarkar wrote: >>> Proposal for issue 124 as outlined in [1] is attached. >>> >>> -Anish >>> -- >>> >>> [1] >>> http://lists.oasis-open.org/archives/sca-bindings/201003/msg00000.html >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]