Forwarded message 1
Hi Stuart,
Williams, Stuart wrote:
> Herve, AFTF,
>
> Generally this is a good piece of work and I like the direction. I have a
> couple of minor comments... but all-in-all a good job... thank you.
>
> I'm conscious that I am looking at two versions... the version that you
> circulated [1] and the version [2] that David references [3]. I assume that
> [2] is the version that we are being asked to review on today's call.
You're correct, the last version is at [2].
>
> <comment>
> [1] retains the distinction between inbound and outbound messages which was
> introduced to avoid 'muddle' once we allow inbound and out bound messages to
> overlap in time. I was pleased to see that in [1] and surprised (a little)
> to note its absense in [2]. I prefer that the distinction be maintained, it
> would be more consistent with Part 2.
> </comment>
I think that [1] was somewhat specialized for request-response MEP, but
that in [2] we generalized the feature so that it could be used with any
MEP.
According to [2], you have an instantiation of the feature's properties
for each message that use this feature. In the case of the
request-response MEP, if both the inbound and outbound messages use the
feature, you will have an att:SOAPMessage and an att:SecondaryPartBag
for the inbound message and another att:SOAPMessage and another
att:SecondaryPartBag for the outbound message. This scheme can easily be
extended to MEP with multiple inbound and outbound messages.
However, I think that other features will want to use this strategy and
currently it is not clear from Part 2 that this is feasible. I'll
probably propose some text to clarify Part 2.
> <comment>
> The other piece that I feel is awkward is notion of precidence between
> att:SOAPMessage etc. and reqres:InboundMessage etc. We might well have to
> live with this for now. The cleanest approach might have been just to add
> the SecondaryPartBag properties, either under att: or as part of context:
> (the latter is probably where InboundMessage and OutboundMessage should be
> rather than under reqres: or maybe we just need a msg: prefix instead...).
> Then, the Primary/SOAP Message part would be carried in the same property as
> the relevant MEP description rather than having to introduce the linguistic
> contortions in a the note:
>
> <quote>
> Note: the att:SOAPMessage and att:SecondaryPartBag properties may conflict
> with other properties (from a MEP or another feature) defining the message
> sent. It is up to the implementation to specify which properties supersede
> the others. However, in most cases, several properties defining the message
> sent could be initialized by the SOAP node according to their specification,
> as long as all those properties are in accordance. In particular, a MEP
> specific property defining the whole message sent would represent the
> compound SOAP structure.
> </quote>
>
> ie. we could benefit from a little cleanup in Part 2 that would enable a
> little more coherence between Part 2 and this feature description. [This is
> 'would-be-nice'... not 'got-to-have'.
> </comment>
My understanding for reqres:InboundMessage is that in represents the
*whole* message exchanged.
<quote>
An abstract structure that represents the current inbound message in the
message exchange. This abstracts both SOAP Envelope and any other
information structures that are transferred along with the envelope.
</quote>
So in the case of attachments, I think that reqres:InboundMessage should
represent the Compound SOAP structure, while att:SOAPMessage represents
the Primary SOAP message and att:SecondaryPartBag represents all the
Secondary Parts.
The intent of the note is to warn that there may be many properties
representing the message or part of it and that an implementation should
be carefull of not messing things up.
Maybe would could change the sentence:
<quote>
It is up to the implementation to specify which properties supersede the
others.
</quote>
to
<proposal>
It is up to the implementation to specify how all those properties interact.
</proposal>
Hope this help,
Hervé.