OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bindings] Issue 25: AI to figure out where we are on this


Eric Johnson wrote:
> Seems like you're restating a number of the MUSTs from the rest of the
> text,

Which MUSTs are being repeated here?

> but you've got some criteria for choosing a subset that escapes
> me.

Not sure what you mean?
(1) says:
The implementation MUST comply with all statements in Appendix XXX.
This appendix XXX would be a summary of all the statements that contain 
2119 keywords. See the assembly spec for an example.

>  Also feels like it doesn't help to clarify the requirements when
> those "MUST" statements are taken out of context.
> 

One of the things that other specs have done is to clean up their 2119 
statements so that they make sense on their own.

> Further, as you reference, the editors have an action item to produce a
> table of all the conformance statements at the end of the spec.  So with
> your proposal, we've got "MUSTs" in section five that repeat both that
> appendix, and the text itself. 

The text itself isn't repeated. It is just a pointer that says you MUST 
do what is in that appendix.
The reason this is valid is, some specs have things that are 'optionally 
normative', i.e., if you support feature X, you must do it a certain way 
but you don't have to support X to conform. For example, SOAP 1.2 intent 
is not required to be supported to be conformant.

> I'm also assuming that the appendix
> would be non-normative(!), so if by some editorial mishap, one of the
> MUST statements from the text is missing, it doesn't matter if it is not
> in the table.

The table is generated automatically, so shouldn't be the case.

> 
> I'd prefer to see the "new" conformance statement in line with the rest
> of the text that relates to the MUST.

Not sure what you mean. Can you elaborate on this? Or perhaps send an 
alternate proposal.

-Anish
--

> 
> -Eric.
> 
> Anish Karmarkar wrote:
>> Here is a proposal to resolve issue 25 based on the direction
>> discussed during the last virtual f2f.
>>
>> Change section 5 from:
>>
>> -----
>> Any SCA runtime that claims to support this binding MUST abide by the
>> requirements of this specification.
>>
>> The normative web services binding XML Schema can be obtained by
>> dereferencing the XML Schema namespace, and is also included for
>> convenience in Appendix A. The <binding.ws> element MUST be valid
>> according to its XML Schema.
>> -----
>>
>> to:
>>
>> -----
>> 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 XXX:
>> Conformance Items related to an SCA Runtime, notably all MUST
>> statements have to be implemented.
>> 2) The implementation MUST conform to the SCA Assembly Model
>> Specification Version 1.1 [Assembly].
>> 2) The implementation MUST support the SOAP.1_1 intent.
>> 3) The implementation MUST support the @wsdlElement and @wsdlLocation
>> attributes of the <binding.ws> element.
>> 4) The implementation MUST support a WSDL binding identified by the
>> WSDL element {http://schemas.xmlsoap.org/wsdl/soap/}binding that has
>> the @transport attribute with a value of
>> "http://schemas.xmlsoap.org/soap/http";.
>> 5) The implementation SHOULD support the SOAP.1_2 intent.
>> 6) The implementation SHOULD support the <EndpointReference> element.
>> 7) The implementation SHOULD support a WSDL binding identified by the
>> WSDL element {http://schemas.xmlsoap.org/wsdl/soap12/}binding that has
>> the @transport attribute with a value of
>> "http://schemas.xmlsoap.org/soap/http";.
>>
>> The normative web services binding XML Schema can be obtained by
>> dereferencing the XML Schema namespace, and is also included for
>> convenience in Appendix A. The <binding.ws> element MUST be valid
>> according to its XML Schema.
>> -----
>>
>> Note that Appendix XXX refers to the appendix that will contain all
>> the tagged normative statement. This proposal is based on the approved
>> conformance text from Assembly spec.
>>
>> -Anish
>> -- 
>>
>> Anish Karmarkar wrote:
>>> On the last call I mentioned that a proposal for 25 was made and
>>> there was a discussion on an earlier call. I took an AI to figure out
>>> where we are on this.
>>>
>>> The proposal and relevant discussion starts at [1]. At the virtual
>>> f2f [2] we did discuss this at length. We ended with the following
>>> revised proposal:
>>>
>>> 1) MUST for: SOAP.1_1 intent, @wsdlElement, @wsdlLocation,
>>> {http://schemas.xmlsoap.org/wsdl/soap/}binding with
>>> transport="http://schemas.xmlsoap.org/soap/http";
>>> 2) SHOULD for: SOAP.1_2,
>>> {http://schemas.xmlsoap.org/wsdl/soap12/}binding with
>>> transport="http://schemas.xmlsoap.org/soap/http";, sca:EndpointReference
>>>
>>> We did not vote on this because SimonN requested that we resolve
>>> issue 54 first, since his vote on this proposal would depend on the
>>> resolution on issue 54. So there is a dependency on 54.
>>>
>>> -Anish
>>> -- 
>>>
>>> [1]
>>> http://lists.oasis-open.org/archives/sca-bindings/200902/msg00049.html
>>> [2]
>>> http://www.oasis-open.org/apps/org/workgroup/sca-bindings/download.php/31216/SCA%20Bindings%20minutes%202009-02-10.doc
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]