Re: Issue 6413- A-J: Discussions

Geoff,

Thank you for all your emails, my computer feels a little heavier ;o) 
Apologies for not responding before (Friday and Monday were UK bank 
holidays).  Here are answers to your questions/concerns.

Best regards,
Katy

A) Dialect attribute:
Processing of the dialect attribute is trivial and provides an efficient 
way to indicate how to interpret the XML body of the transfer messages 
which will not burden tiny implementations. 
Using a SOAP headers to indicate the processing of the message body is a 
way to shoe-horn extensibility into a spec and splits the extensibility 
processing between the SOAP layer and the implementation layer (not 
ideal). 
In addition to this, there is a serious problem with the specification of 
T.Create() currently as there is no way for the server to know how to 
interpret the XML (as highlighted in separate issue 6712).  The dialect 
attribute fixes this problem.

B) We could simply loosen the text in the main body spec in order to 
ensure that dialect semantics do not change core specification semantics. 
(For example "This REQUIRED element MUST contain at least one child 
element - by default the representation to be used for the update.")   The 
key thing we need to ensure is that the 'main purpose' of the Envelope is 
in the Body in order for this information to be potentially accessible to 
the application.

C) Yes, this is a good point.  Mandating that the extensibility elements 
must always be ignored if the dialect is not specified may be too 
restrictive.  Perhaps we could not state anything about the processing of 
the xs:any if the dialect is not specified?

D and E) The proposal does not drop any function from RT, it simply moves 
the core single fragment use case to T. 
Issues http://www.w3.org/Bugs/Public/show_bug.cgi?id=6422 and 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6803 are valid issues that 
should be considered separately to this one.

F)  Please could you be more specific as I am not aware of any 
syntactic/semantic changes to the core XPath definition?

G) The core fragment use case was the one that Dave and I were tasked with 
providing a proposal for in the March F2F.  Here: 
http://www.w3.org/2002/ws/ra/9/03/2009-03-11.html

H) We don't explicitly call out the status of the appendices 
(normative/non-normative)  for other specs - why should we here?

I) The dialect attribute will allow more complicated dialects if required 
so the spec is no more restrictive by defining one dialect. I don't think 
your questions are specific to the dialect proposed and perhaps should be 
addressed under a separate issue (spanning WSRT).

J) We are not marking other WS-RA features 'at risk'  at this stage, there 
is no reason to do so for this one.




From:
Geoff Bullen <Geoff.Bullen@microsoft.com>
To:
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Date:
11/04/2009 01:10
Subject:
Issue 6413-J: May Not Meet Candidate Recommendation Exit Criteria.  Was: 
Issue 6413: WS-Transfer with Extensible Fragment Support



Issue J: May Not Meet Candidate Recommendation Exit Criteria
 
The Working Group is not aware of the required critical mass to implement 
the proposed advanced features and related interop scenarios, and test 
interop to exit the Candidate Recommendation (CR) phase. Given that, we 
request these features should be marked ?at risk? from day one. This will 
help the Working Group to drop these features if they do not meet the CR 
exit criteria.
 
--Geoff
 
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr
Sent: Wednesday, March 25, 2009 9:23 AM
To: public-ws-resource-access@w3.org
Cc: David Snelling; Doug Davis
Subject: Issue 6413: WS-Transfer with Extensible Fragment Support
 

Following discussions on issue 6413 during the March F2F, Dave and I were 
tasked to create a new proposal that integrated basic fragment support 
(from WS-RT) into WS-T: http://www.w3.org/2002/ws/ra/tracker/actions/39. 

Dave, Doug and I have worked on this and have the following proposal: 

A key requirement of this action item was minimum change to the core WS-T 
specification (as the amount of change to the WS-T spec was a concern with 
the initial proposal).  With this in mind, our proposal adds only an 
optional 'Dialect' attribute to each operation.  This attribute specifies 
how the extensibility elements in the in the body will be processed - thus 
providing a fully extensible mechanism to the WS-Transfer spec, but with 
minimum changes. 

We were sensitive to the fact that WS-T implementations should not need to 
process the soap body unnecessarily.  The dialect attribute has the useful 
side effect of indicating whether processing of extensibility elements in 
the soap body is required.   More importantly, its absence indicates when 
processing is not required.  For the Get and Delete operations, (where 
processing of the body is not necessary if there is no extensibility), we 
state: "When this attribute is not present, child elements of the wst:Get 
MUST be ignored." 

In terms of dialect definition, we have defined one dialect only: XPath 
Level 1 Expression Dialect and this is contained in Appendix A. 
Implementation of this dialect is optional and other (optional) dialects 
may be defined by other specifications.  The XPath Level 1 Expression 
Dialect was chosen because it satisfies the core fragment use cases 
without introducing additional complexity.   XPath Level 1 restricts the 
evaluation of an XPath 1.0 expression to a single element thus providing 
simple fragment support for the majority of use cases.  Multiple elements 
could still be targeted via an XPath Level 1 expression by inclusion of a 
parent element by the application to encapsulate child multiple elements. 

Note the following with respect to the defined  XPath Level 1 expression 
dialect: 
- We have restricted the dialect to disallow multiple fragment support 
(i.e. only one expression/fragment per request).   Again, this was to 
ensure that we were covering core use case without introducing unnecessary 
complexity. 
- For simplification, we have not introduced the Put 'Mode' element from 
WS-RT.  Fragment deletion may be performed with Delete and the XPath Level 
1 expression dialect.  Fragment insertion may be performed with Create and 
the XPath L 1 Dialect. 

Note that the schema has not been updated to reflect the proposal as it 
seemed prudent to await decision by the group prior to spending time on 
this. 

The proposed document with markup in word and html is here: 
http://www.soaphub.org/public/files/w3c/WSTWithBasicFragmenSupport.htm 
http://www.soaphub.org/public/files/w3c/WSTWithBasicFragmenSupport.doc 

Thanks, 
Katy 



 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 












Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU