6413 2009-01-14 00:15:01 +0000 Transfer- Move Fragment support from RT to Transfer 2009-08-18 21:14:34 +0000 1 1 1 Unclassified WS-Resource Access Transfer FPWD PC Windows XP CLOSED REMIND http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0029.html hasProposal P2 normal --- 6398 6392 6803 1 dug dug bob public-ws-resource-access-notifications oldest_to_newest 23059 0 dug 2009-01-14 00:15:01 +0000 The features of WS-ResourceTransfer are a natural extension of WS-Transfer and really should be part of the WS-Transfer spec itself. The reason for the current split is mainly history. Now would be the time to merge the fetures of RT into T so that we remove the need for an additional specification and reduce the complexity for the implementators and end users. Proposal: Move the following features from RT in T: - Fragment support Pull would then become: <wst:Get Dialect="xs:anyURI"?> <wst:Expression ...> xs:any </wst:Expression> * </wst:Get> Note: if Dialect is not present then wst:Get acts like it does today. In other words, the child of wst:Get becomes the full representation of the resource. PullResponse would then becomes: <wst:GetResponse> <wst:Result ...> xs:any </wst:Result> * </wst:GetResponse> <wst:Put Dialect="xs:anyURI"?> <wst:Fragment Mode="Modify|Insert|Remove"> <wst:Expression>xs:any</wst:Expression> ? <wst:Value ...>xs:any</wst:Value> ? </wst:Fragment> + </wst:Put> Note: if Dialect is not present then wst:Put acts like it does today. In other words, the child of wst:Put would becomes the full representation of the resource. Create would become: <wst:Create Dialect="xs:anyURI"?> <wst:Fragment> <wsmex:Metadata> ... </wsmex:Metadata> ? <wst:Expression>xs:any</wst:Expression> ? <wst:Value ...>xs:any</wst:Value> </wst:Fragment> * </wst:Create> Note: if Dialect is not present then wst:Put acts like it does today. In other words, the child of wst:Create would becomes the full representation of the resource. - Move over the Dialects - Move all faults associated with these features. Note: if we do this then some of the other issues I've opened about BP compliant will go away because this already adds a wrapper/GED to the child of the env:Body. 24066 1 bob 2009-03-05 22:32:39 +0000 New proposal in http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0021.html 24150 2 bob 2009-03-11 09:54:19 +0000 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0052.html 24184 3 bob 2009-03-12 00:31:38 +0000 Action-39 on Katy 24427 4 bob 2009-03-29 22:18:19 +0000 proposal in http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0121.html at http://www.w3.org/2002/ws/ra/9/03/Issue-6413-2009-03-25.html 25873 5 bob 2009-07-06 14:41:29 +0000 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0001/6975_6413_proposal_06-01c.doc 25900 6 bob 2009-07-07 19:51:08 +0000 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0006.html 25908 7 bob 2009-07-08 06:09:25 +0000 2009-07-07 Resolved with the proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0006.html amended with the text "Use of this URI indicates that the contents of the Delete element should be processed as specified by the WS-Fragment [WS-Fragment] specification. to "Use of this URI indicates that the contents of the Delete element MUST be processed as specified by the WS-Fragment [WS-Fragment] specification. applied as appropriate where the underlying text appears in all four operations.