W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

RE: AFTF: new draft (resent)

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 18 Jul 2002 08:58:10 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A06F65@0-mail-1.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT