My apologies, but I forgot to mention in my last email that I've got a
conflict with the call tomorrow, so hopefully my comments stand on
their own.
-Eric.
On 03/24/2010 10:59 PM, Eric Johnson wrote:
4BAAFBC7.9040903@tibco.com" type="cite">
Hi Anish,
On 03/24/2010 02:51 PM, Anish Karmarkar wrote:
4BAA8976.1090906@oracle.com" type="cite">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.
4BAA8976.1090906@oracle.com" type="cite">
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.
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?"
Likewise for BWS50013 & 50014.
4BAA8976.1090906@oracle.com" type="cite">
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.
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.
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"
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:"
-Eric
4BAA8976.1090906@oracle.com" type="cite">
-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
|