Re: Mapping XMLP glossary onto SOAP spec

Henrik,

Thanks for the comments.  Here are a few more thoughts that I think clarifies
the targeting point.

Mark


Henrik Frystyk Nielsen wrote:

> Thanks Mark for the review - here are my comments...

>
> >2. XMLP Header or Body
> >
> >From an abstract model point of view, I still don't see a
> >compelling difference between header blocks and body blocks.
> >The only distinction in the definitions for XMLP header and
> >XMLP body is that the body forces targeting to the ultimate
> >XMLP receiver.  From an abstract model point of view this is
> >no real distinction.
>
> >From what the abstract model point describes as of now I have no problem
> with this. However, there are more subtle points like how the RPC
> convention interacts with headers and bodies that the model doesn't
> include as of yet.
>
> Also, we have other requirements that do encourage a separation into
> something like header/body, namely:
>
>         http://www.w3.org/2000/xp/Group/xmlp-reqs-06/#z802
>
> >From a concrete syntax point of view, it
> >may offer some brevity, but it also seems to introduce some
> >mischief.  If several handlers wish to contribute a mixture of
> >header and body blocks in a return message, it will be harder
> >to serialize the reply if the blocks must be grouped into
> >Header and Body constructs.
>
> I am not sure I can see a common scenario where this is the case - do
> you have one?
>

I'm not sure, but there may be versions of the traceroute scenario where each
intermediary writes a block targeted for the final destination.  If the
processing of each of these blocks generated both a header block for some
reason and a body block with the traceroute info, that would be an example.

Traceroute is also an interesting example of a somewhat different issue with
header and body blocks.  If we think of intermediaries as only contributing
header blocks, traceroute is a case where the meat-and-potatoes blocks are
the headers blocks, not the body blocks (if indeed there are any).  In a very
real sense, the intermediaries are really supplying the true "body" of the
message.  This may again point out the artificiality of the header/body
distinction.

>
> >3. XMLP Handler and Module
> >
> >The handler and module stuff gets into the thorniest issues.
> >The proposed glossary changes aren't as objectionable to me as
> >the overtones in the discussion.  SOAP takes the view that
> >"not differentiating between the handlers and the processor"
> >is a virtue.  I see it as a vice from the standpoint of a
> >sender wanting to "target" a block to a particular behavior.
>
> In the SOAP model, the way this is addressed is by using links. If I
> have a block that contains a vcard for example and another block that
> talks about signing data then I can point the signing block at the vcard
> block and that this is the signed data but the signed data itself is not
> aware that it is being pointed to.
>
> However, if I have to say within or as an annotation of the vcard block
> that I want to use it for signing then I run into problems with a single
> block being used for multiple things and if the use of a block changes
> while being exchanged. By using links, we
>
> A) avoid having to talk about handlers in any dispatch related manner

I'm not saying you can't do it with links, but especially in the case where
you are only requesting one of the possible actions on a vcard (even if many
appropriate handlers are available at this node), it means that you end up
with a rather gratuitous block that exists just to point to the vcard block
and get the right handler invoked.

My point was that you actually do sort of end up talking about handlers in a
rather roundabout way.  You invent very specific tags
<process-vcard-this-way> and <process-vcard-that-way>.  These basically
become shorthand (or longhand) for invoke the handler to
"process-vcard-this-way" or the handler to "process-vcard-that-way".  That
doesn't particularly seem more elegant to me.

>
> B) allow for blocks that are not associated with any modules (just
> "data")

If some blocks were targeted at a module, it does not follow that all blocks
would have to be.  You can still use the link scheme, also.  The ideas are
independent.

>
> The *how* one wants to use the data within a block is a function of the
> link that one can make to that block and not of the block itself.

Correct.  See above.  You've just indirectly targeted the handler/module in
the referencing block.

>
> Note that the vcard block itself may be part of no module at all - it
> might just be a bag of bytes that I want to exchange in the message.

No problem with doing that.  Not every block would have to be targeted.

>
> Henrik
>
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0212.html
> [2] http://www.w3.org/TR/REC-xml-names/

Received on Thursday, 29 March 2001 22:07:05 UTC