[Fwd: Re: AFTF: new draft (resent)]

attached mail follows:

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é.