PnF minutes 20030401

Participants:
 Amy, Glen, Steve, Philippe, Paco, Sanjiva
Regrets:
 Jean-Jacques

Review of action items:
 Glen to write why it should a property instead of an XML
element/attribute
  (pros and cons)
  *pending*

 Philippe to write his HTTP features/properties proposal
  *done* ->
http://lists.w3.org/Archives/Public/public-ws-pnf-tf/2003Mar/0025.html
 Glen to contact Paco
  *done*

--- 
Review of the HTTP feature and properties proposal
 http://lists.w3.org/Archives/Public/public-ws-pnf-tf/2003Mar/0025.html

Glen: setting for abstract property name needs to be specified twice?

Philippe: no but one can assume that it is possible to deduce the method
used in the binding by looking at the abstract feature level. Problem
happens with the limitations of bindings, e.g. for HTTP GET, you cannot
use complexType. In such case, even if you use the retrieve property at
the abstract level, you will still use POST. I see the abstract level as
a hint and not anything else.

Glen: there's sort of a disconnect with names in the soap binding. it
would be nice to have a single name for things, maybe we should question
the whole approach.

PLH: you do have a point in that you have to repeat the operation but
soap is using "soap" inside their feature and it may lead people to
think than even our HTTP binding is using SOPA underneath. 

Glen: then its a naming issue. if we think this is important, can we ask
the soap group to change the 1 uri? do we think its worth stirring the
pot?

ACTION: Philippe to write comment to soap group that we have encountered
this
and forward the proposal

Philippe: still have issue with http headers

ACTION: forward to group and include http headers issues

---
Topic: ws policy intro

 http://www-106.ibm.com/developerworks/library/ws-polfram/

Paco: document provides common container - very generic approach. policy
element encodes set of assertions. connectors combine sets of
assertions. attributes qualify the assertions. name policy by uri or
qname. have attribute such as usage that could have a value of
"required", "optional", or "observed". or "rejected" or
"ignored". policy reference element allows textural embed to allow reuse

http://www-106.ibm.com/developerworks/library/ws-polatt/

Paco: if you attach a policy to a porttype, then every porttype has to
support the policy. if you attach a policy uri to port or service,
you're saying that the port or service supports the policy. would like
to have a property or feature that supports a policy

Glen: it seems that policy and feature are similar things

Paco: nothing to prevent defining a feature using a policy uri

Philippe: could you have properties and features within a policy?

Paco: policy can reference other policies

Glen: features are blobs that come from above; policy comes from below
and provides semantic for expressing this stuff

Philippe: do we need to introduce qnames in features as well?

Glen: properties were qnames when they 1st went into the spec; then
changed. don't have a canonical qname to uri translator. features &
properties model already defined in 1.2; not going to change

Philippe: going to have to do mapping for qnames between policy and
features/properties

Received on Tuesday, 1 April 2003 16:45:57 UTC