Re: AM corrections

Mark, Stuart,

Here are some further comments regarding the AM, and in particular
section 4.2.

I hope this helps,

Jean-Jacques.

----

> Each block has an optional associated id (identifier), an optional
> actor and an optional mustUnderstand flag.  The id is an ID that
> identifies the block for the purposes of reference by other blocks.
> The mustUnderstand flag has value "1" if  the intended semantics of
> the block must be carried out and "0" (the default) otherwise.  The
> actor is a URI which identifies the XMLP processor that is intended
> to process the block.

I think the above paragraph may be a little too "concrete", and
describe details that may be best reserved for the spec itself (for
example: describing mustUnderstand is a "flag"). I propose that we
revised the wording as follows. This would have the additional
benefit, IMHO, of aligning this section better with the rest of the
document, and in particular with section 3.2 "Operations Parameters"
(Message, Messaghe.Blocks, Message.Attachements, Message.Faults).

"Each XMLP block has the following sub-fields: Block.Id, Block.Actor,
Block.MustUnderstand. Block .Id is an optional identifier that
identifies the block for the purposes of reference by other blocks.
Block.Actor identifies the XMLP processor that is intented to process
the block. Block.MustUnderstand specified whether the intended
semantics of the block must be carried out or not."

> There are reserved actor URI's with special significance (actual
> syntax to be determined):
>   .../none    // an untargeted block (may be referenced by other
> blocks)
>   .../next    // matches the next processor (basically a wildcard
> that matches any processor)
>   .../final  // matches the final processor

Inline with my earlier comment, I suggest the following wording
instead:

"The following values for Block.Actor have special significance: Next,
Final, None. Next matches the next XMLP processor (basically a
wildcard that matches any XMLP processor). Final matches the final
XMLP processor. None is for untargetted XMLP blocks (blocks that may
be referenced by other blocks).

> The XML Protocol blocks are ordered within the envelope.  This order
> is followed by each processor as it selects and processes blocks,
> yielding a limited facility for specifying sequential constraints.
> Two alternatives are available for more complex orderings and
> constraints.   Hierarchical constraints can be achieved by
> syntactically scoping blocks inside one another.  Finally, blocks
> can be incorporated by reference (using the "id" and "href"
> attribute mechanism).  Using these techniques, more elaborate
> "manifest" blocks which direct the processing of other blocks can be
> designed.  From the processor's point of view, only the outermost
> element of the block is seen.

I suggest we move the text in paranthesis to the spec itself : "using
the "id" and "href" attribute mechanism".

> The processing of a block may result in a fault or a successful
> evaluation.  A fault terminates processing and causes a return
> message containing the fault to be generated if a return path is
> available.  It is possible for a module that processes a block to
> have status information, non-fatal errors, or other results
> incorporated into the return value generated by the ultimate
> recipient.  It can accomplish this by inserting blocks which are
> targeted to http://.../final.

I suggest we replace the last sentence with:

"It can accomplish this by inserting blocks which are targeted at the
final destination."

> The fully qualified name of the top element of a block identifies
> the block.

I suggest we move the above sentence to the spec itself. I think it
may be too specific for the AM.

Received on Monday, 2 April 2001 08:50:42 UTC