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


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?

-Anish
--


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