Minutes PnF 20030325

Participants: Glen, Sanjiva, Jean-Jacques, SteveL, Philippe

Regrets: Colleen, Paco, Amy
 
Glen: work items:
 WSDL items, and FnP architecture
1- finish the usage scenarios and produce concrete WSDL syntax.
 we may have to talk about larger scale things while doing this...
 example: exposing SOAP Action has a feature
2- FnP Architecture
3- WS Policy and overlap

extension in WS Policy are not properties/features based.

Sanjiva: transaction context and relations with WS Policy.  the
transaction context should be describe in an independent manner, not
only SOAP headers.

Glen: we need to have a look at it as well. terminology issue or
architecture problem?

Sanjiva: Paco is co-author of WS Policy, we probably need him around.

Glen: it would be nice to have a WS-Policy presentation from Paco and
see how we connect to it.

Sanjiva: WS-Policy is more general than WS, you can attach a policy to
any element.

Glen: no matter what we do, it is good to have rules on how to identify
and tweak those things.

---
SOAP Action

Glen: when you write a binding spec, you list the features and
properties and that's it.  if you want to add more things, make a new
binding. or you write a spec to complement the existing binding.

JJM: is it like the SOAP binding?

Glen: could be WSDL binding as well.

Glen: for SOAP Action, there is a SOAP action parameter and goes into
the mime type.  now, I can write code that sets that and come with a
WSDL element/attribute for that.  but, if we want to PnF and URIs based
properties, you need to define a property for that. Who defines it then?
if XMLP says it's too late, we have 2 choices: put some english wording
in the WSDL spec, or define a feature (SOAP Action feature) and say that
the value of the property goes into the mime type.

JJM: is it a specific or a larger question?

Glen: this does not change the binding behavior at all. we're just
giving a URI wouldn't be ok since the reason to have URIs is to let
multiple parties to recognize the same things. in this case, it's ok.
changing the meaning of the URI is probably not ok.  how far can you go
into tweaking the meaning of the URI? by recognizing the binding URI,
you agree to recognize all features and properties that is represent. if
2 specs defines those features/properties, you may have issues.  in
WSDL/Core, it's ok, but with a proliferation of specs, we may run into
troubles.

JJM: if we want to avoid an exponential explosion of URIs, one way to
keep the same URI but in WSDl to list the features that are actually
supported by that binding.

[Jean-Jacques leaves the call]

Philippe: you'll face the problem whether you use features/properties or
XML element/attributes.

Glen: we can mark them as required. SOAPAction is optional, moved into
the mime type. it would nice to have a way to describe it.

Sanjiva: you have a SOAPAction element in WSDL 1.1. People use
SOAPAction to indicate some processing on the server side.

Glen: the only issue is soap:action or introduce a property.  we could
do the same thing for web methods.  this SOAPAction might be use in an
other binding as well.  do we have to change the SOAP http binding, or
leave it to another spec?  how to expose the constant string for
SOAPAction in WSDL?  2 questions: should it be a property and facilitate
collaboration between specs? and if yes, where do you define it?  the
fact that you mark it down as a property, you can write code that uses
those. you can reuse the same API to access properties.

[Sanjiva leaves the call]

ACTION: Glen to write why it should a property instead of an XML element
(pros and cons)

ACTION: Philippe to write his HTTP features/properties proposal

ACTION: Glen to contact Paco

Received on Wednesday, 26 March 2003 16:53:45 UTC