Forwarded message 1
Hi Marc,
> -----Original Message-----
> From: Marc Hadley [mailto:marc.hadley@sun.com]
> Sent: 17 July 2002 12:13
>
> 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.
Hmmm... properties whose value types can be indirect references to other
properties... the explaination makes sense and I guess its admissable under
a loose interpretation of the defnitions of reqresp:InboundMessage and
reqresp:OutboundMessage:
From Part 2 Table 8:
<quote>
reqres:OutboundMessage: An abstract structure that represents the current
outbound message in the message exchange. This abstracts both SOAP Envelope
Infoset (which MAY be null) and any other information structures that are
transferred along with the envelope.
reqres:InboundMessage: An abstract structure that represents the current
inbound message in the message exchange. This abstracts both SOAP Envelope
Infoset (which MAY be null) and any other information structures that are
transferred along with the envelope.
</quote>
Actually... I thought we had expunged the "other information structures"
concept but it appears not. Anyway a strict interpretation says that a
reference to a structure of some type is not a structure of that type, and a
loose interpretation says "yeah, well... but we know what we mean and all
this stuff is a bit abstract anyway... so be practical."
I think the fact of OutboundMessage and InboundMessage being reused across
the MEPs that we have defined and likely being reused in future MEP
definitions suggests we organised them under the wrong prefix and in an
ideal world they would be under "context:" in table 2. This feature spec
could then give some sub-structure to the "abstract structure that
represent..." such that:
context:OutboundMessage.SOAPMessage carries a primary part and
context:OutboundMessage.SecondaryPartBag carries the
corresponding secondary parts
But... I have not participated in the AFTF and its probably too late to
introduce or argue these ideas - however I think that would have been what I
would have advocated had I participated in the TF.
> 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.
I'm sure a diagram would be helpful.
> 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.
Well the "Note :" text feels awkward and it would be nice to not have to
include it - the "Note :..." uses the works 'conflict' and 'supercede'. It
seems to point at a possible problem and sort of wave its hands and say...
but with care its not really a problem.
So... No... I don't think it does address the second problem until the AFTF
have a narrative that doesn't require the awkard "Note :".
> Cheers,
> Marc.
BTW... I don't want to argue hard about these things. I do think this is a
good piece of work and I can live with it as presented.
Regards
Stuart