Hi Stuart,
> 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:
IMHO, I would rather add a new scope for the properties. Currently,
Section 5.1.2 of Part 2 defines two differents scopes for properties :
- Environment scope
- Message Exchange Context scope
I think that the Environment scope is really a multiple level scope,
from a system wide scope to a user specific scope. And I think that the
Message Exchange Context scope should have at least two levels: the full
Message Exchange Context scope, i.e. properties applying to all the
messages exchanged, and a Message scope for each message exchanged,
allowing to use the same feature throught the same properties for
different messages.
>
> 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:
I agree that either we sould define the OutboundMessage and
InboundMessage properties under another prefix, or add a note in the
SOAP Response MEP description saying that the reqres:OutboundMessage and
reqres:InboundMessage is not a typo.
>
> 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.
This solution, while nice, only works for MEP that can use our would be
context:OutboundMessage and context:InboundMessage properties for
defining their messages. A MEP which has 2 outbound messages cannot use
our context:OutboundMessage property and so will not be compatible with
the Abstract Attachment Feature.
Moreover, I think it would be signaling in the wrong way for the
specification of other features: we "own" the "context" prefix, so we
can add new properties to it. But other people should not define new
properties with the "context" prefix, otherwise, we would lose all the
benefits of namespaces.
>>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.
I attached a new version of the diagram to this mail. It will be
included in a future version of the draft, as soon as possible (and if
the WG agrees).
Hope this help,
Hervé.
