RE: Mapping XMLP glossary onto SOAP spec

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

>1. block vs. header/body entry
>
>I am OK with the analysis and proposed resolution.
>
>Henrik makes the point that we should tighten up the
>definition of block by specifying that it should be 
>"identified by the fully qualified name of the outer element 
>for the block, which consists of the namespace URI and the 
>local name."  While I don't have any problem with that, it 
>begs the question of what we mean by "identifying a block".  

In order to fit well with other XML technologies, I think the intent is
to use the XML namespace [2] model of identification based on a fully
qualified element name.

>It seems to me that even in the SOAP scheme, the header and
>body entries are easily 'identified' as the immediate child 
>elements of the Header and Body elements.  So what is the 
>import of 'identified'.  Does it mean "what you will use to 
>determine how to process the block"?

I don't think so - the fully qualified name identifies the block. It
says nothing about *what* (in the sense of a piece of software) a SOAP
processor might invoke in order to deal with it.

>If so, then I think that
>might already be prejudicing a dispatch mechanism and gets 
>into design. If it just means at some point it may be 
>important to fully resolve the tag name, then that's fair enough.

That I think is the case.

>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?

>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
B) allow for blocks that are not associated with any modules (just
"data")

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.

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.

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 16:01:36 UTC