Forwarded message 1
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.
<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>
<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>
Anyway, comments aside, a nice piece of work. Thank you.
best regards
Stuart
[1]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jul/att-0081/01-
aftf-soap-af.html
[2] http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html
[3]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jul/0082.html
> -----Original Message-----
> From: Herve Ruellan [mailto:ruellan@crf.canon.fr]
> Sent: 16 July 2002 12:46
> To: w3c-xml-protocol-wg@w3.org
> Cc: David Fallside; John Ibbotson; Marc Hadley; Henrik
> Frystyk Nielsen;
> Mountain Highland M; Christopher Ferris
> Subject: AFTF: new draft (resent)
>
>
> Dear all,
>
> I sent yesterday a revised draft for the SOAP 1.2 Attachment
> Feature. It
> apparently didn't reach the list. Here it is again and sorry for the
> inconvenience.
>
> I did highlight changes in this new version, however changes
> are mainly
> localised to:
> - Section 5 Attachment Feature properties
> . Removed att:AttachmentScheme property and previous section 5.1
> . Changed OutboundSecondaryPart<N> to OutboundSecondaryParts
> . Changed InboundSecondaryPart<N> to InboundSecondaryParts
> . Rewrote 5.1 and 5.2 (old 5.2 and 5.3) to be more state machine
> description like.
> - Changed various sections and contents to reflect
> undertermined nature
> of the document (this forced modifying the stylesheet, however it is
> still very close to the previous one).
> - Updated a few dangling references.
>
> Comments are welcomed,
>
> Hervé.
>