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

proposal for 8193 and 8185

From: Doug Davis <dug@us.ibm.com>
Date: Mon, 22 Feb 2010 15:08:56 -0700
To: public-ws-resource-access@w3.org
Message-ID: <OFB819995B.E398D06A-ON852576D2.005C7821-852576D2.0079AD2A@us.ibm.com>
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
The more I'm around some people, the more I like my dog.

Received on Monday, 22 February 2010 22:09:59 GMT

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