W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > March 2010

RE: proposal for 8193 and 8185

From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
Date: Tue, 2 Mar 2010 02:34:34 +0000
To: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <503546C5699C1144BDEA0D0DFFE7F881229B1313@TK5EX14MBXC112.redmond.corp.microsoft.com>
I have some feedback on the proposal:


*       Replace mode

o   Using Replace to Remove seems non-intuitive. Suggest retaining the existing Remove mode.

o   When the expression points to a non-existent fragment, shouldn't Replace generate a fault?

*       Insert mode

o   Since this adds to the end of a collection, Append seems to be an appropriate name for this mode.

Thanks.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, February 22, 2010 2:09 PM
To: public-ws-resource-access@w3.org
Subject: proposal for 8193 and 8185


All,
  attached is a proposal for 8193 and 8185.  Some of the edits leave the strict boundaries of the issues but they are edits that really need to be made as they were really exposed during the work on these issues - as you'll see in the following summary:
- there's a new section at the top of the spec that talks about identifying the fragment of the resource.  The current version of the spec talks about these concepts at various places in the spec, so for readability I moved them all into one section.  For example, it talks about how batching is not supported and what an implementation should do if the expression results in more than one node.  None of this was Language specific so it makes sense to have it in one generic location.
- This new section also talks about whether attributes are simple strings or whether they can be multi-values expressions.  This was related to Gil's issue.  As of now we just say its a single string.  If we want to change this we can later on but I think its really a separate issue.
- I moved the serialization rules out from under the XPath Language section into a new section up top.  This is because its not Language specific.
- Also, I modified the text to say that the serialization rules DO apply to Put request - and not just to Get response.  This is because of the ambiguity around how to interpret the wsf:Value children.  For example, is "foo='1'"  a string to be added as a child of the current element, or does this mean that a new attribute should be added?  This will also allow for other types of XML constructs to be added (under a different issue), like processing instructions, or XML comments - if we want.

- The rest of the edits relate to modifications of the Mode values.
- Replace is now a 2 step process - "Remove" followed by "Insert".  This allows for a cleaner design because it ensures that the same "Insert" logic can be used for both "Replace" and normal "Insert".  Because of this, "Delete" is now gone.  You can get the same end result by just leaving off the "Value" element.  It seemed wrong to have two ways of doing the same thing.
- "Insert" always inserts the wsf:Value stuff as children of the referenced element (whether its a node or attribute).
- There are two new Modes - insertBefore and insertAfter.  These are specifically there to deal with adding elements into sequences/arrays.  Without this we have no way of knowing if we're supposed to add a new element as a child or as a sibling to the referenced element.
- I added a table that shows the "before" and "after" representations based on a set of example expression/values.  I think this will go along way towards making sure people not only understand how it all works, but also expose any holes in our design.




thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.
Received on Tuesday, 2 March 2010 02:35:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:24 GMT