Forwarded message 1
On Wednesday, July 17, 2002, at 10:41 AM, Williams, Stuart wrote:
>
> <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>
>
The reason for this is a that the feature is intended to be MEP
independent. It is designed to be used in conjunction with an MEP
so that, e.g. when used with the request reponse MEP both
reqre:OutboundMessage and reqres:InboundMessage would 'point' to
separate 'instances' of the attachment feature. There was a diagram
circulated with an earlier draft that made this much more obvious -
Herve, would it be worth putting it back in to the current draft.
Does the above address your comment below too ? I.e. there is no
precedence problem since reqres:InboundMessage 'points' to an
'instance' of the attachment feature.
Cheers,
Marc.
>
> <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é.
>>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.