See also: IRC log
<trackbot> Date: 26 January 2010
<DaveS> Request for the following issues for tomorrow from Ram:
<DaveS> 6435, 6436, 8196, 8205, 8290
<DaveS> These will be dealt with tomorrow.
<DaveS> Doug reviewed the above document.
<DaveS> Key Points:
<DaveS> - How do we advertice "feature" WSDL?
<DaveS> - Then how do we distinguish the different types of WSDL?
<li> sorry have to drop off for an urgent call
<DaveS> The proposal moves the feature wsdl to a position after the advertizement of the feature in the policy assertion.
<DaveS> It also provides a WSDL Mex request only returns the application WSDL. The others come from the assertions.
<DaveS> Tom: Could the feature WSDL ever also be an application WSDL?
<DaveS> Doug: Yes, but probably out of scope of this WG.
<DaveS> Asir: For clarity, we are talking about associating metadata (e.g. WSDL) with the feature policy assertion?
<DaveS> Doug: Yes.
<DaveS> Doug: the proposal is general in the sense that it associates metadata with it feature assertion.
<DaveS> Gil: Asserts that Eventing specifies only one WSDL for an endpoint.
<DaveS> Confirmed A.2.1 of eventing
<DaveS> Doug: The point may be valid if there are multiple WSDLs associated with the assertion.
<DaveS> The policy creator has the option to do it however, the need.
<DaveS> Asir: How do we reference multipl schema docs.
<DaveS> Doug: Thses would be included (via includes) in the WSDL.
<DaveS> Ram: Are we restricting this to one artefact?
<DaveS> Dooug: Short answer - no restriction, but guiadance to wrap these based on the feature type.
<DaveS> There was a short detour into Paul's concerns.
<DaveS> Doug: The same pattern may apply to Paul's issues.
<DaveS> Asir: Asir believes that there is a different pattern.
<DaveS> Look at the transfer assertion, a QName only.
<dug> <wst:Resource ...> xs:QName </wst:Resource>
<DaveS> Doug: This QName referes the type.
Asir: There is a resource policy
assertion param, that indicates the QName.
... Do you want to use the same pattern?
<DaveS> Doug: the problem is not really knowing which element in the collection would refer to the resource type.
<DaveS> Asir: Can we use the same pattern in both both?
<DaveS> Doug: Feels they are different, because in the Ws-T case we don't know which is refeing to the resources.
<DaveS> Doug: Basically, each feature would have it's own WSDL.
<DaveS> Asir: The same for other features, e.g. frag's dialect assertion.
<DaveS> Asir: Would like to study more.So on to the next bit.
<DaveS> - Need a list of assetions where this applies?
<DaveS> - Need to identify the assertions where extenibility need to be addressed.
<DaveS> - Does this apply to Paul's issue?
<DaveS> Doug: For the first, we can do it for the specs we control, but other should be encouraged to follow the pattern.
<DaveS> It is not clear what the question about WS-T means.
<DaveS> - We need to make the ecommendation to other users explicit.
<DaveS> Example walk through:
<DaveS> See WSDL+EventSource.
<DaveS> This shows how to assert that Eventing is supported.
<DaveS> See: Next section
<DaveS> This one defines event description metadata.
<DaveS> This one shows how to add WSDL.
<DaveS> This example may help with the WSDD discussion.
<DaveS> Ram: This does seem to work, but ....
<DaveS> Asir: The mail suggestes that it needs to be more abstract
<DaveS> Doug: E.g. in the PortType.
<DaveS> Bob: Assuming that we are happy with this approach, then the WSDD might be solved by moving this to the PortType.
<DaveS> Next Example:
<DaveS> This one inlines a specific WS-Eventing WSDL document.
<DaveS> This one provides a specific (different) address for events.
<DaveS> Next Example:
<DaveS> Sam as above, but links to metadat rather tan inlined.
<DaveS> Two approaches are shown.
<DaveS> Asir: These are new features:
<DaveS> Doug: Include new feature for Mex (two flavours)
<DaveS> There seems to be a slight difference from the pattern in the Mex document.
<DaveS> Asir: Are the semantics dependent onthe semantics of the parrent?
<DaveS> Doug: MEX does not say anything specific.
<DaveS> So this association may move the semantics, e.g use an include here rather than inlining.
<DaveS> Asir: Why not add a new context free element?
<DaveS> Doug: Do we add new elements to Mex.
<DaveS> Asir: No, use new generic elements.
<DaveS> Doug: Good point, don't use the element from eslewhere.
<DaveS> Asir: Sounds good.
<DaveS> See example Metadat in an EPR
<DaveS> As before the exaples forllow a progressing addition of more complexity.
<DaveS> Review the Summary section:
<DaveS> The EPR discussion may be ssociated to another issue, but not critical here.
<DaveS> Consider droping this issue here and deal with it under the other issue.
<DaveS> Need to check carefully which issues are closed by this approach.
<DaveS> See section "One of the nice things ...."
<DaveS> All metadata could appear in one place.
<Tom_Rutt> which bullet?
<DaveS> See beginning of the document.
<DaveS> By using the ?wsdl (or mex.GetMetadata("wsdl") mapping is very easy to explain.
<DaveS> Asir: Currently their is no equivalent to ?wsdl.
<DaveS> Gil: The application gets to descide what "wsdl" means.
<DaveS> It is unclear what ?wsdl means, so it make this dificult to define.
<DaveS> Gil: The app developer could create a single document (mostly like ?wsdl).
<DaveS> Gil: Get Metedata can return a lot of stuff. get wsdl would return just one wsdl.
<DaveS> Doug: A get wesdl operation that colsely follows "wsdl pattern.
<DaveS> Jeff: What do I need to know to use the bag of stuf.
<DaveS> Doug: this proposal aim to address this problem.
<DaveS> Jeff: The get wsdl at least we know the schema of what comes back.
<DaveS> A diversion about giving up on GetMetadat entirely.
<MartinC> isnt that a meta-meta model jeff
<DaveS> Asir: Some advanced tools can deal with less information.
<DaveS> Doug: Let's do this and talk about some other details later.
<DaveS> Jeff: the metamodel of WSDL is available.
<DaveS> Bob: Are we agreed that this is a good road to fiollow?
<DaveS> Doug: Next step is to make the Mex and Eventing spec cahnges.
<DaveS> Asir: Why don't we make Doug do them all?
<DaveS> Bob: Only if Asir is really happy with the approach.
<DaveS> Asir: There are some bullets that need addressing. Doug should go for all of them in all the pecs and let's push forward.
<DaveS> Specific on the new elements.
<DaveS> Doug: Wants agreement generall and will attack the spec ASAP.
<DaveS> Resloution: We have directional agreement based on the 5 bullets avove.
<DaveS> Fresh names.
<DaveS> get WSDL.
<DaveS> Postpone Paul's issue when we get there.
<DaveS> List of assertions.
<DaveS> Recommendation to other spec writers
<DaveS> Policy assertion on the porttype.
<Tom_Rutt> what is next?
<DaveS> Since Martin is here 7986 will be next.
<Tom_Rutt> Do we know when will 8196 and 8229 (namespace issues) be discussed?
<Bob> tom, sometime this afternoon I hope
<DaveS> Toipc: 7986
<DaveS> How does the EventSink know the available policies available?
<DaveS> Gil: An event source can send notification.
<DaveS> The sink can say, please do it this way.
<DaveS> This can be placed in the notify EPR.
<DaveS> How does the sink know what approaches are likely to work.
<DaveS> Doug: If the source can publish notification wsdls this is a sloution
<DaveS> But this is not required, e.g. it uses event descriptions.
<DaveS> No concrete proposal yet.
<DaveS> DaceS: Is this really needed?
<DaveS> Doug: Forcing use of not. wsdl or fault driven discovery is not good enough.
<DaveS> Without Not. WSDL where is thin information available.
<DaveS> Doug: Because Not. WSDL is not required, but for this bit of information to be available, this is the only way at present.
<DaveS> Asir: This is providing policy for the next level of interaction. Similar to Paul's request.
<DaveS> Doug: Proposal to define another policy parameter that could be used in a notify to EPR.
<DaveS> Gil: Identify all the available poilcies and provide only the ID.
<DaveS> Doug: Is this possible?
<DaveS> Asir: You can used named policy assertions.
<DaveS> Asir: You can name the policy..
<DaveS> A list of experssion can each have a name, but an expression with alternative won't fly.
<DaveS> Resoultion: This seems a reasonable (if not very tasty) direction.
<DaveS> Doug: Should be covered by the MOAP proposal.
<DaveS> The support for that resolution being allowed on the portType as well.
<DaveS> Fred Maciel Joins
<DaveS> Gil: A portType now could include binding specific policy.
<DaveS> This is not really a good idea.
<DaveS> An advisory could probably be added, here.
<DaveS> Asir: Accouring to Anton there is something about the associatin cardinality rules.
<DaveS> WU; We know how to do the bindings, but just need the abstract information (ie the association.
<DaveS> Doug: This should be possible at the portType level.
<DaveS> Doug: It may be silly to put binding info in the portType, but so what. It could also be profilesd.
<DaveS> Gil: It seems that we might be agreeing. The parameters are important.
<DaveS> they have WSDLs, therefore you have to support it
<DaveS> Wu: You only do the matching at the assertion level. The parameters provide further information.
<DaveS> Gil: These parameters are surely important.
<DaveS> Wu: It is untamately no proble to provide binding information in both places.
<DaveS> Resolution: This one should be closed along with MOAP
<DaveS> Gil: What can we say to push developer toward a recommended dialect.
<DaveS> Shold we point to XPath 1.0
<Bob> Support for the XPath 1.0 dialect (described below) is RECOMMENDED. Alternate filter
<Bob> dialects can be defined. Such dialect definitions MUST include sufficient
<Bob> information for proper application.
<DaveS> Gil: Is this implying that filter is recommended.
<Bob> If filtering is supported, then support for the XPath 1.0 dialect (described below) is RECOMMENDED. Alternate filter dialects can be defined. Such dialect definitions MUST include sufficient information for proper application.
<DaveS> RESOLUTION: 8275 resolved as above.
<DaveS> Doug: Does this apply to Enum as well?
<DaveS> Doug: There is a place for this in Enum.
<DaveS> RESOLUTION: 8275 will aslo apply to Enumeration.
<DaveS> Gil: There is a proposal and it's a good one.
<DaveS> RESOLUTION: 8288 resolved as proposed and modified by comment #1
<DaveS> Ram: there is a dependency between this one and 8302
<DaveS> Ram: These look like the same issue.
<DaveS> Ram: Targets two messages (Create/Put Response). Have a look at the text changes.
<DaveS> The crux is that there is something unclear about what happen with extension elements.
<DaveS> Doug: Works for no extension element, but what about when they are there?
<DaveS> Ram: Today the spec requires that you need to have the representation.
<DaveS> Asir: Spec the rep comes first the extensions.
<DaveS> Ram: In the spec, the response says the rep. must be there. Same in Create and Put.
<DaveS> Doug: Likes the Put Response wording.
<DaveS> Gil: Put response sounds good until the last sentence. (assuming mutating ....)
<DaveS> Ram: What this means is that there may be other changes made concurrently.
<DaveS> Gil: this may confuse some implementations.
<DaveS> Yves: This is good to say.
<DaveS> Maybe a seperate sentence could be better.
<DaveS> Text requested:
<DaveS> Ram is mailing the text to the mailing list.
<DaveS> Gil: Does this work with 8299 as well as 8302?
<DaveS> Doug: 8180 looks like a part of this as well?
<DaveS> Maybe, but not now.
<asir> ACTION: Doug to prepare a concrete proposal for issue 7986 based on the direction established by the Working Group [recorded in http://www.w3.org/2010/01/26-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-137 - Prepare a concrete proposal for issue 7986 based on the direction established by the Working Group [on Doug Davis - due 2010-02-02].
Remove the sentence "This second child element, if present, MAY be an empty element depending on the resource representation." from the above proposal from CreateResponse.
<DaveS> Gil: 8299 is addressed for put, but this may not be as clear for create response.
<DaveS> Ram: First is the EPR then the representation.
<DaveS> Gil: How do we know that?
<DaveS> The problem also exists in 8180
<DaveS> Doug: Do we just drop thie extensibility in responses`?
<DaveS> We will do these two tomorrow.
<DaveS> Break for one hour while we tweak the text.
<Bob> we resume
Continuing discussion on issue 8302 and 8299
<Bob> scribenick: Ram
Gil: Presents proposal
<Bob> continuing on 8302
Dave: Does an extension in the request result in a subsequent extension in the response.
Gil: Should the resource manager create a representation that differs from what was supplied.
Doug: The current text was intended to create a resource that is close enough to what was supplied.
Gil: The current text does not reflect that.
Dug: I am wondering if we should take
a step back and approach this differently.
... A Resource Manager can change the resource anytime.
... It may be useful to put a paragraph that states that above.
... The other thing to do is, to look at the problem, and say the bare minimum.
... The extensibility seems more important. But should the resource representation be returned?
... Should the representation allow for explicit empty element.
Ram: Should we discuss 8180?
Bob: Park this discussion for the moment.
Gil: Should you return the resource representation?
Bob: Sending back a large representation as a result of a small change may not be useful.
Ram: It may be useful to have empty representation form for Put and Create requests to null out the resource.
This empty resource must appear on all operations..
Then remove returning the resource representation from CreateResponse and PutResponse.
<Tom_Rutt> can the scribe summarize?
<dug> 1) if the representation is in a msg it must be wrapped with <wst:Resource/> no matter what operation we're talking about.
Ram: Having the representation in PutResponse and CreateResponse is complicated.
Gil: The resource may change change inadvertantly?
<Bob> ack \
Doug: I agree with Gil.
<dug> Proposal: 1) add a paragraph in a generic spot that talks about how the res. mgr can modify the resource for a lot of reasons. 2) define/add <wst:Resource/> to all operations. 3) remove implicit Get for Put/Create-Response.
Tom: I am in favor of getting rid of
... I am in favor of getting rid of the optimization.
Bob: Are folks OK with adding a wst:Resource element?
This allows distinguishing the representation from extension elements.
<Tom_Rutt> Clarification of my question: Is this the semantics of put: "DO WHAT YOU CAN, GIVE A SUCCESS RESPONSE IF YOU CAN DO ANY OF IT, THEN LET THEM DO A GET TO FIND OUT WHAT REALLY HAPPENED?
Dug: It is not good for the resource manager to return a huge representation in the response.
<dug> Proposal: 1) add a paragraph in a generic spot that talks about how the res. mgr can modify the resource for a lot of reasons. 2) define/add <wst:Resource/> to all operations. 3) implicit Get - discuss tomorrow
<Bob> tom, your answer is happening now
Ram: How does the client know if the service created the resource as requested or not?
Doug: The service cannot guarantee at all.
Bob: 8299, 8302, and 8180 are woven
... Create a comprehensive proposal for all three issues.
Dave: I have some reservation about adding <wst:Resource/>.
Dug: I would rather have a model that all cases including extensions.
Criteria to consider:
1. Allow extensions.
2. Diambiguate the representation <rep><A/></rep> vs <rep/>
3. The resource manager may do more to the created/updated resource than create.
4. Ram: Investigate if there needs to be an resource representation in the CreateResponse and PutResponse.
AI: Gil has the AI to prepare proposal for 8299, 8302, and 8180.
<dug> "For example, it would need to define the context (which data) over which the filter operates."
Dug: In our zeal to remove advertisement to XPath 1.0, we removed the above sentence.
The above amendment to 8275 was accepted without objections.
<Bob> AI: Gilbert has the AI to prepare proposal for 8299, 8302, and 8180.
<Bob> ACTION: Gilbert has the AI to prepare proposal for 8299, 8302, and 8180. [recorded in http://www.w3.org/2010/01/26-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-138 - Has the AI to prepare proposal for 8299, 8302, and 8180. [on Gilbert Pilz - due 2010-02-02].
Bob: Is 7791 soaked up by MOAP proposal?
Dug: Yes, it should mostly.
Yves: Looks good.
Bob: Any objections?
Issue 7774 resolved with above proposal.
RESOLUTION: Issue 8181 resolved as proposed.
Gil: Someone convinced me that this was not a good idea.
Dug: Suggest closing with no action since this is addressed.
Gil: This is not the case where you
can look at the request is not valid.
... It is the case where it is only invalid because of the state of the resource at the point of the Put request.
... Is there a need for a special fault in this case?
Bob: Any objections to close with no action?
RESOLUTION: Issue 8182 closed with no action.
Bob: Gil, what kind of serialization rules are necessary.
Asir: What serialization rules are being asked for?
Doug: This is NOT an editorial change.
Gil: There is no clarity on the WS-Fragment about how the serialization work with Put.
Dug: You can construct an XPath that points to multiple things.
Ram: How does this relate to the request from the XML Security WG about seperating out the XPath expressions from the core protocol?
Gil: Can the Expression point to multiple nodes?
Bob: The purpose of XPath is
essentially to address a point/location.
... What can you do to that point is the question.
... Are you going to change all the attributes in a single Fragment Put is a question?
... It can get complex.
Dug: The WS-Fragment says for XPath 1.0: "An XPath 1.0 expression MAY evaluate to multiple nodes; because of this the XPath 1.0 language MUST NOT be used with a "Put" or "Create" operation."
Gil: A clarification on the Put is sufficient.
<scribe> ACTION: Doug: Work with Gil on proposal. [recorded in http://www.w3.org/2010/01/26-ws-ra-minutes.html#action03]
<trackbot> Sorry, couldn't find user - ITEM
<Ashok> ACTION: Dug to work with Gil on proposal for 8191 [recorded in http://www.w3.org/2010/01/26-ws-ra-minutes.html#action04]
<trackbot> Created ACTION-139 - Work with Gil on proposal for 8191 [on Doug Davis - due 2010-02-02].
Ram: This related to 8193.
... The specification does not talk about inserting attribute nodes.
<Tom_Rutt> hai: transport ack not application ack
Bob: We need some concrete text.
<scribe> ACTION: gpilz to Produce a concrete proposal. [recorded in http://www.w3.org/2010/01/26-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-140 - Produce a concrete proposal. [on Gilbert Pilz - due 2010-02-02].
Ashok: We are going through these many difficult cases. We ought to remember that there is this specification called XQuery update which does all these. The XQuery has details on how to do the XML update.
Dug: Having an attribute to indicate Insert instead of Replace would work for me.
<Tom_Rutt> I am checking out for the day, hear you tomorrow morning
Bob: Why can't you use an Insert for non-array nodes?
<Ashok> XQuery update language: http://www.w3.org/TR/xquery-update-10/
Doug: In XPath can you do a
... Can you insert an first child?
Bob: If the child count is zero, an
insert will introduce the first child element.
... Insert and Replace has distinct semantics.
Doug: Would it work in the case of attributes?
Bob: For replacement, you need to
know the specific attribute.
... I can write a conceptual outline.
ACTION Freund to produce a conceptual model
<trackbot> Created ACTION-141 - Produce a conceptual model [on Bob Natale - due 2010-02-02].
Conversation on XPath semantics ensuing.
XPath allows you to point to a location. Insert and Replace allows you to manipulate data at that location or around it.
Bob: Any objections to resolve as proposed?
RESOLUTION: Issue 8257 resolved as proposed.
Bob: Any objections to removing
Create from "XPath 1.0 language MUST NOT be used with a "Put" or
... Isn't it true that the ability to support multiple nodes dependent on the expression languages.
ACTION Doug to investigate with Katy/Ian why the Put has to be restricted to first selected node.
<trackbot> Created ACTION-142 - Investigate with Katy/Ian why the Put has to be restricted to first selected node. [on Doug Davis - due 2010-02-03].
Ram: It is important to separate the
protocol semantics from expression language semantics.
... The protocol should NOT disallow using sophisticated expression languages.
... The specification should define at least one usable expression language.
Ram describes his dissertation.
Gil: When implementation/tools point
to WSDLs, what do I need to do a reasonable event sink?
... I want to implement that derivations of the WS-Eventing WSDL is BP compliant.
... So the implementations are interoperable.
Wu: I don't think we can limit WS-Eventing binding only to HTTP or SOAP 1.1.
Correction: I don't think we can limit WS-Eventing binding only to HTTP or SOAP 1.1.
Wu: We should follow WS-Addressing
and WS-Policy and follow their lead.
... It is beyond scope of what we are attempting to do here.
Jeff: If we leave it to people's good judgements, why do we need standards?
WSDL 1.1 is NOT a standard.
BP 1.1 is an ISO standard.
Jeff: We want to say WSDL 1.1 as
modified by BP 1.1.
... It is not to restrict what is allowed, but to ensure interoperability.
Wu: Why doesn't anyone complain about WS-Policy?
<Ashok> WSDL 1.1 W3C Note 15 March 2001
Asir: BP 1.2 and 2.0 when it becomes an Final Material can be useful but NOT Basic Profile 1.1.
Jeff: Should we defer until BP 2.0 is done.
Bob: You could do that.
... Should we wait until BP 1.2 and 2.0 become Final Material?
... We can safely defer this until after Last Call.
Jeff: Could we put some text in the specification to clarify use of WSDL 1.1?
Doug: Could we have a section in BP 1.2 and 2.0 that pertains specifically to fixing WSDL 1.1 issues only?
Asir: Should we consider closing this without prejudice and reopen it later?
Jeff: No we cannot close this. We should defer.
Bob: Should we defer this until after
Last Call at least.
... At least until CR.
Jeff: If we can come up with a proposal, we should consider resolving it.
Asir: What are the trip wires to process this issue?
Bob: 1) A new proposal 2) BP 1.2 and 2.0 are Final Material 3) We reach Candidate Recommendation and we decide what to do.
RESOLUTION: 8284 will be addressed after Last Call
Meeting is recessed until tomorrow.