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] Attempt #4 at WSDL binding

Hi Anish,

Anish Karmarkar wrote:
> Eric Johnson wrote:
>> Hi Anish,
>> Anish Karmarkar wrote:
>>> Eric Johnson wrote:
>>>> Hi Anish,
>>>> Anish Karmarkar wrote:
>>>> [snip - At the risk of having removed too much context from the
>>>> discussion.]
>>>>> The bigger question, is do we want our default binding to be
>>>>> interoperable, if yes, then we should stick to BP conformance with
>>>>> some minimal exceptions. Anything else, define your own WSDL binding.
>>>>>> If you think this really is an error, is seems that the assembly
>>>>>> specification must state something normative about how
>>>>>> interface.wsdl
>>>>>> portTypes cannot be any odd WSDL 1.1 portType, but they must be WS-I
>>>>>> BP 1.2 compliant portTypes.  But I don't think it should.
>>>>> I don't think we need to go that far. If someone wants to do BP
>>>>> non-compliant portType they can, but they have to define their own
>>>>> bindings. Don't rely on defaults.
>>>> That sounds like a decent approach.  I'll have to think about it more
>>>> prior to our next meeting, but it seems like a reasonable constraint -
>>>> if the portType is not compatible with BP 1.2, then the user must
>>>> explicitly provide their own binding.
>>> Ok. If we agree on that, then the only issue would be about whether to
>>> allow rpc/literal or not for the default bindings. If we want to allow
>>> it, we'll have to provide a SCA-defined default namespace for the rpc
>>> wrapper element and the part accessors.
>> My take is that we should allow it - we've been talking about supporting
>> it up until now, so yes, we need that namespace identifier.
> I'm ok with that.
> I had suggested before that if we want to allow rpc/literal then we
> provide a *fixed* NS URI. I'm beginning to think that a fixed NS URI
> that is used by everyone may not be a good idea. Instead we might want
> to use the hierarchical URI associated with the component and add
> "service-name/binding-name" to it.
> What do you think?
That sounds reasonable to me.


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