Re: Reqs/AM - Comments/Questions

Jean-Jacques wrote:
>> - 6.1 Glossary
>>   - Missing XMLP Processor
>Which version of the glossary are you looking at? The XMLP/SOAP spec[1]
>contains a definition  for an "XMLP/SOAP processor".
>>   - XMLP block & XML handler
>>     This needs to be an M-N relationship.
>For targeted blocks, the relationship is currently M-1 (processed blocks
are
>removed from the message). For untargeted blocks, the relationship is M-N
>(untargeted blocks are never removed from the message, although they may
be
>processed as a result of processing targeted blocks).

There is a M-1 relationship between targeted blocks and XMLP processors
not handlers.  It is possible that within a single XMLP processor
the work of processing a single header might be split across multiple
handlers, in which case it become an M-N relationship between targeted
blocks and handlers.

>> - 2. XML Protocol Abstract Model Overview
>>   - XMLP Handlers should be an implementation detail.  XML blocks
>>     should be targeted by using the XMLP equivalent of the SOAP
>>     ActorURI and it should be up to each XML Processor to decide how
>>     that Actor is interpreted.  It could be the entire processor or
>>     a particular module (ie. handler) in that processor or even a
>>     group of handlers.
>Some people believe an XMLP processor should be a standard component
>(similar to an XML parser) that dispatches blocks to modules/handlers
>according to well-known (normative?) conventions. In that model,
processors
>do not do any processing on their own. Other people view this as an
>implementation issue, and consider that at least some processors will
>process blocks directly, for example on resource constraint devices.
>>     We need to be very careful about this one - defining handlers
>>     could lead to some problems, lets say we have an XMLP message
>>     like:
>>     <env>
>>       <header mustUnderstand=1>...DigSig stuff...</header>
>>       <body>...</body>
>>     </env>
>>     and neither the header nor the body are targeted (ie. no actors).
>>     This means that they're implicitly targeted for the final
>>     destination of the message
>My understanding is that non-targeted header blocks are never processed,
>unless referenced by at least one targeted block.

non-targeted headers are implicitly targeted for the ultimate destination.

>> - 3.1.1 Correlation of Sending and Receiving XML Protocol Applications
>>   - Why is Correlation special?  Why is this one field pulled out
>>     into the APIs?  Can't the same argument be made for any field (ie.
>>     user-id)?  Would it be cleaner to define "well-known" headers or
>>     Actor URIs for this purpose - that way everything about the message
>>     is kept inside of the SOAP Envelope.
>Correlation was brought out so we could deal with 2-way messages. We need
>2-way messaging (at least) for RPC.

So does this mean that we're changing the definition of SOAP from
one-way messaging to possibly two-way?  And if so, how does this
relate to our goal compliance with existing SOAP implementations.

>>   - Bullet 7 - Does the fault happen immediately or can we wait until
>>     the end of the current XMLP handler/processor?
>My understanding is that a fault is a failure that cannot be recovered
from,
>so processing of the message at that node will fail immediately.

There have been discussions in some soap forums about allowing the
processing to continue in order to get as many error messages as
possible returned to the user.  If this is something we want to
disallow then we need to say so.

>>  Do we allow multiple
>>     faults to be returned?
>One (fatal) fault, but several errors, I believe.
>> - 5.1.1 Introduction
>>   - Figure 5.1 should show XMLP Handlers may generate output -  ie. may
>>     talk directly to the bindings.
>I think handlers are not supposed to talk directly to bindings, at least
>conceptually. They should fill in a binding template, and pass it down to
>the XML layer for doing the actual binding.

That's an implementation detail/choice - so I think the AM doc shouldn't
lead people to think there's only way to do it.

-Dug

Received on Monday, 7 May 2001 23:05:05 UTC