RE: AFTF: new draft (resent)

Hi Herve,

> -----Original Message-----
> From: Herve Ruellan []
> Sent: 17 July 2002 14:41
> To: Williams Stuart
> Cc: 'Marc Hadley';
> Subject: Re: AFTF: new draft (resent)
> Hi Stuart,
> > Hmmm... properties whose value types can be indirect references to other
> > properties... the explaination makes sense and I guess its admissable
> > 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.

Ok... however, I think that this is an extension of the convention described
in Part 2 section 5 [1].

What I think that you are allowing is a property value to be a reference to
another context structure of some kind (in this case you've called it a
Compound SOAP structure) which is itself another property container. Cool...
hadn't thought of 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.
> 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.

Now I understand what you have proposed I'm fine with that. The diagram
really helped.

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

What you're introducing (which extends the model at [1]) is almost a way of
doing complex value typing for property values (by reference to a
subordinate context that carries an expected set of property values). Yes...
I think that is neater than extending out the property names with facits
(which is also an extension to the model BTW).

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

I'd still like you to find away to remove the awkward "Note" from the text.
In fact, if what you explained to me here is clear in the document, I don't
think that the note is necessary.

Thanks again,

Best regards


Received on Thursday, 18 July 2002 03:58:40 UTC