See also: IRC log
<trackbot> Date: 02 March 2010
<Dug_> I may be in-n-out- got an HVAC guy here fixing something
<Yves> li
<Yves> Sreed
<Yves> Tom RUtt
<Yves> Dug
<Yves> Katy
<Yves> Ram
<Yves> Asir
<Yves> MartinC
<Yves> Alessio
<Yves> VIkas
<Yves> Scribe: Alessio
<Yves> Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Feb/0037.html
RESOLUTION: minutes approved
Dug: can we add 2 topics to agenda? definition and use of extension, use of policy parameters
Yves: agree as it's part of MOAP
<asir> what are we promising to discuss?
gpilz: please leave some space to discuss about soap version wrt MOAP
<asir> sounds like WSDL
<Dug> link: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Feb/att-0022/wsfrag-8193-8185-v5.doc
<Dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Mar/0001.html
<asir> there is a fax noise on the line
<li> ringing...
<asir> someone is making a point using a fax
we should require a value for replace mode
gpilz, we need to consider the use cases here
gpilz, 80% use case is just "set this value"
Ram, why not using "add" instead of Insert
<Dug> If the expression is invalid per the xsd, assuming xsd checking, then it MUST generate an invalidExpression fault
<Dug> add to the end of replace
<Yves> Proposal is Dug's proposed text amended by * Replace mode, and * Add
<Yves> plus text above
Yves, objections?
RESOLUTION: issue 8193 and 8195 are closed with the resolution above
can extensions modify base behaviour?
Ram, a client should be able to ingore extensions that have been made to a server
Dug: extensions should not violate the base assertion
gpilz, we need some way for requiring an extension to be understood and used
gpilz, so that if you don't understand them,you can't communicate at all
asir, in soap we have mustunderstand, in policy we have nested policy expressions
Dug, as long as the nested assertion does not violate/contraddict the base behaviour, there's no real problem
<Dug> If an Element Information Item is not recognized, it MUST be treated as a policy assertion, unless specified otherwise such as in Section 4.3.4 Policy References.
gpilz, you can't ignore policy assertion you don't understand unless that's marked as ignorable
Dug, if the extension is there there's most probably a reason, so this is a good behaviour
Dug, this relates to when we can ignore policy parameters
<Dug> If an Element Information Item is not recognized, it MUST be treated as a policy assertion, unless specified otherwise such as in Section 4.3.4 Policy References.
asir: make policy parameter in the parent assertion not ignorable, parameters in the extension ignorable instead
<Dug> Within normative outlines, in this specification, ellipses (i.e., "…") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension. In this context, if an Attribute...
<Dug> ...Information Item is not recognized, it SHOULD be ignored. If an Element Information Item is not recognized, it MUST be treated as a policy assertion, unless specified otherwise such as in Section 4.3.4 Policy References.
<gpilz> Within normative outlines, in this specification, ellipses (i.e., "…") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension. In this context, if an Attribute Information Item is not recognized, it SHOULD be ignored. If
<Yves> http://www.w3.org/TR/ws-policy/#Policy_Assertion_Nesting
<Yves> http://www.w3.org/TR/ws-policy/#normalization
<asir> I don't understand what I am asked to provide a reference for
<li> ws-policy 3.1 Assertions indicate domain-specific (e.g., security, transactions) semantics and are expected to be defined in separate, domain-specific specifications.
a bit..
<Dug> Tom: Both
<li> section 3.1 Authors MAY define that an assertion contains a policy expression (as defined in 4. Policy Expression) as one of its [children]. Nested policy expression(s) are used by authors to further qualify one or more specific aspects of the parent policy assertion. The qualification may indicate a relationship or context between the parent policy assertion and a nested policy expression. For example within a security domain, security policy authors may define a
dug: asir, please show us where what you say about policy assertion is in the policy spec
<asir> don't know what you are asking me to point to
li: take a look at text I pasted
asir: we decide the extensibility logic in the assertion
<asir> i don't understand what i need to provide
<Dug> please show in ws-policy where it says extensions SHOULD/MUST be ignored and where extended nested assertions are ignored or forbidden.
Tom_Rutt, think the policy spec do not clearly allow or prohibit this
<Tom_Rutt> there is nothing in the policy framework spec which states we cannot define a policy assertion type which can allow additional nested expressions. However, there is not statemment in policy framework 4.3.2 that states we can do it either. It seems silent
asir / dug: any policy expression is an assertion and can't be ignored
dug /gpilz: please send an email to ML that point to relevant pieces of the policy spec talking about this topic
<asir> First part of the q
<asir> 2.2 Extensibility
<asir> Within normative outlines, in this specification, ellipses (i.e., "�") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension. In this context, if an Attribute Information Item is not recognized, it SHOULD be ignored. If an Element Infor
<asir> Second part of the question
<asir> from MEX
<asir> 3.3 Considerations on the Use of Extensibility Points
<asir> The elements defined in this specification MAY be extended at the points indicated by their outlines and schema. Implementations MAY add child elements and/or attributes at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver SHOULD ignore that extension. Senders MAY indicate the presence of an extension that has to be understood through the use of a c
dug: where does policy spec say extension should be ignored
<gpilz> <wsp:Policy> xs:any </wsp:Policy>
asir: part 2 is not controlled by the policy spec
<gpilz> we don't own the WS-Policy namespace
<Dug> If an Element Information Item is not recognized, it MUST be treated as a policy assertion
ashok: that's another context
Yves: we're running out of time, please review the minutes very well
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Asi/Asir/ Succeeded: s/reply/require/ No ScribeNick specified. Guessing ScribeNick: asoldano Found Scribe: Alessio WARNING: No "Present: ... " found! Possibly Present: Ashok_Malhotra Doug_Davis Dug_ Gilbert_Pilz Katy MartinC Microsoft Ram Sreed Tom Tom_Rutt Vikas Yves aacc aaee ashok asir asoldano dug gpilz joined li link trackbot ws-ra You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Feb/0037.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Mar 2010 Guessing minutes URL: http://www.w3.org/2010/03/02-ws-ra-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]