- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Thu, 18 Jul 2002 08:58:10 +0100
- To: "'Herve Ruellan'" <ruellan@crf.canon.fr>
- Cc: "'Marc Hadley'" <marc.hadley@sun.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi Herve, > -----Original Message----- > From: Herve Ruellan [mailto:ruellan@crf.canon.fr] > Sent: 17 July 2002 14:41 > To: Williams Stuart > Cc: 'Marc Hadley'; w3c-xml-protocol-wg@w3.org > 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 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. 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. <snip/> > > 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 Stuart [1] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#soapfeatspec
Received on Thursday, 18 July 2002 03:58:40 UTC