RE: TBTF: In-context Framework Intro.

PS: Feel free to move this to the public list - I have cc'ed
www-archives in the mean time.

>Thanks for taking a crack at this. I've attached a diff 
>version (html and
>.doc) that I've generated by doing a document compare on 
>Noah's and Henrik's versions. I think it highlights the 
>differences in the first couple of pages more clearly.

Good idea...

>I have a couple of concerns:
>
>1) I am concerned that we have removed all distinction between 
>"transport/underlying protocol message exchange patterns" and 
>end-2-end SOAP provided message exchange patterns. 
>Transport/underlying protocol MEPs are scoped for a single 
>hop. SOAP provided MEPs are the patterns that the SOAP layer 
>provides to the things that use SOAP. I think the 
>undistinguished use of plain MEP will lead to confusion. I 
>think that there is a difference between what a binding 
>provides to SOAP and what SOAP provides to SOAP applications 
>which we need to be clear about.

I am actually not sure I can see the benefit of talking about underlying
protocol MEPs - after all we are interested in carrying SOAP messages
around and not of modeling underlying protocols in general. It seems to
me that just as we expose features to SOAP, we expose MEPs to SOAP -
whether they are "native" or not doesn't really matter. Also, it doesn't
seem consistent that we talk about one particular property of the
underlying protocol but not others like intermediaries, say. What
benefit does this distinction bring to the table?

>2) I am concerned about the removal of all the stuff that Noah 
>signalled he had not touched. This probably bears on what it 
>was we thought we'd agreed as a compromise. 

I may have missed something but after having read Noah's discussion and
moved a few things up in the introduction, I could not find anything
that wasn't addressed already with respect to features and MEPs.

>I think that my take away was that we agreed that the property 
>based style of describing features and MEPs would be a none 
>normative convention that we do use within our own work (HTTP 
>binding, MEP and feature descriptions) and encourage others to 
>adopt. The diagram and the narrative that accompanies the 
>diagram effectively provide the setup for that non-normative 
>convention... which needs to be explained somewhere if it is 
>not part of Part 1.

That is fine - I was assuming that the part being edited was intended
for part 1. It may make sense to move the description of properties to
the HTTP binding in section 2 - I haven't touched that at all.

Henrik

Received on Tuesday, 20 November 2001 10:43:38 UTC