Re: Mapping XMLP glossary onto SOAP spec

I took a look at Henrik's mapping of the XMLP glossary onto SOAP 1.1 [1].  Here are my
observations.  Tomorrow (Thursday) I will try to examine whether/how this impacts section 4.1 in
the Abstract Model.

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

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 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 would recommend we wait to
decide if we need this distinction, despite its use in SOAP.
It seems much simpler to just have an Envelope which directly contains zero or more blocks.  If
we ultimately decide that blocks need to be grouped because we also want some non-block elements
in the envelope, then we can simply put them all in a Blocks construct.

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.

As an analogy, think about the fact, for example, that the very same declarative XML (complete
with fully qualified namespace) can be passed through a SAX-style parser with one set of
tag-function mappings and it will compute one thing.  Pass it through the same parser with a
different set of tag-function mappings and it will compute something entirely different.  There
is nothing intrinsic to the declarative XML per se that describes how it should be processed.
There are obviously ways to augment the declarative XML with some behavioral constructs that can
select the particular tag-function mapping to apply -- you could preceed or surround the
declarative XML with other elements that select a mapping, or you could introduce a special
attribute that "targets" the desired behavior.  Alternatively, you could have completely
different environments (different SAX parsers with fixed tag-function mappings) and select the
entire processing environment that gives you the behavior that you want.

Now the same thing can apply to a block.  The block element's namespace URI can be absolutely
neutral with respect to which behavior is desired.  The same block can be processed by many
different types of modules, each having different semantics.  Nothing prohibits several such
modules from co-existing on the same processor.  How does the sender indicate which behavior(s)
are desired?  The potential solutions are much the same as above.  You can encompass or link to
the declarative information by other elements that  effectively target the desired behavior, or
you could introduce a special "module/handler" attribute that indicates the desired behavior.
Alternatively, you could disallow two such modules from co-existing at the same node and force
the desired behavior by routing to the appropriate node.

In any case, it certainly seems fair to say that a sender has to select or "target" the intended
behavior for a block in some fashion.  SOAP allows a processor to be targeted via the actor
attribute.  In some sense, it further allows a targeting of behavior in the fully qualfied
namespace URI of the block element, but this just doesn't seem quite strong enough when the
block is most naturally thought of as declarative and usable by multiple modules.  In this case
you have to resort to encoding the targeting in an additional XML element that encompasses or
links to the declarative block.  It seems to me a matter of taste as to whether you like
targeting your behavior by using additional XML elements or by an attribute that targets a
handler/module.  I happen to like the idea of using the actor URI in an intensional fashion to
name the module, effectively saying "the processor that implements this module (and will use it
to process this block right now!)".

I do not understand the statement that there are many "handlers" which are not part of modules,
unless one adopts a very limited sense of what a module might be -- restricted to signing,
encryption, ..., tracing, etc.  It seems to me that any handler that processes a block is doing
so on behalf of "some service or function that is related to SOAP/XMLP in some manner" ("what we
mean when we talk about a module").  So every handler is fairly easily construed as being a part
of some module, even if the module is little more than the handler and its relationship to a
particular block.  More narrow "application modules" (as opposed to general "service modules"
such as signing, etc.) may surely exhibit all of the complexity and features of service modules.

If you take this view, then it becomes axiomatic that a processor is parameterized by a set of
modules (quite apart from issues of procesor implementation, plug-in mechanisms, etc.).  Except
in rare cases where footprint or efficiency is of overriding concern, I would expect most
processor implementation to have some kind of plug-in architecture, however.  It makes sense
from an information hiding point of view that a processor should not need to know about the
mapping between a block and a handler/module.  If blocks were targeted at modules (something
analogous to an actor, but functional), then the processor could delegate the handler dispatch
to the module.  The processor would invoke some 'dispatch' method associated with the module
that would determine how to process the block.  This method could very flexibly determine how to
process the block:
 * map the tag name to a particular handler, or
 * ignore the block given the current state of the module, or
 * cache the block since it needed to process some other block first, or
 * create a DOM model and then dispatch a handler on that, or
 * set up a set of functional bindings for a SAX parser and  think of the 'handler' as being
those bindings, or
 * etc.

The module is thus the locus of any processing constraints, choice of per-block handler, etc.


Mark Jones
AT&T Labs



[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0212.html

Received on Wednesday, 28 March 2001 22:42:27 UTC