Re: Issue 6413 - just thinking

Yves Lafon <ylafon@w3.org> wrote on 05/06/2009 03:57:52 PM:
> On Wed, 6 May 2009, Doug Davis wrote:
> 
> > XML at each sub-resource location.  But, in the end you still end up 
with
> > a single EPR to a single resource and you're asking the application
> > (Transfer in this case) to act on it.  From an Addressing perspective
> 
> Well Transfer is just qualifying the exchange, so basically your point 
is 
> that it's the application definition that defines the meaning of the 
> fragment.

Well, Transfer is the application is this case - so yes the application is
defining the meaning of how to treat the XML in the Body.  Vanilla 
Transfer
defines Put as "blind replace", while fragment Transfer modified it to be
"interpret the XML as an instruction".

> > that's as fine grained as the client can get.  At that point we're 
within
> > the Transfer application and _if_ people want to ask for finer grained
> > manipulation that's where the Transfer fragment stuff comes into play.
> > We're no longer at the infrastructural/WSAddressing layer - we're 
within
> > the application.  This is why we do not view this as an Addressing 
issue
> > and also why the fragment stuff should be in the SOAP Body and not a
> > Header.  We believe that the application data belongs in the Body but
> > that's probably a different topic  :-)
> 
> Ok, so the logic is different, but if we take this approach, the logical 

> way of defining fragment is along the applicative spec that will consume 

> this definition. In this case, RT, as T doesn't define the application 
in 
> RT. So it seems that the best bet is to put this fragment definition (as 

> it won't be a generic one) back in RT.

This might be true if RT were a separate application but its not.  RT is 
an
extension to T.  This fragment stuff is being done (no matter how its 
packaged in the specs) as part of the T application.

-Doug