RE: Resolving the Ed Note in Part 1 section 5.1 (was New Issues)

Hi Glen,

> This seems to be rather antithetical to the original purpose 
> of abstracting out "features" in the first place.
> 

I'm inclined to agree and I think Noah would to, at least I would read that
into the messages he and I have exchanged on this thread [1,2].

To go where I think you would like us to go, I think we would have work on
articulating SOAP Extensibility interms of feature and properties. I think
this would be a fine place to go... but I do think it exceeds the current
brief of the TBTF and we also have to be realistic about what we can achieve
within a reasonable time. I think that, appealling though it is, taking on
describing SOAP Extensibility in terms of features and properties would have
quite an impact on the narrative of the SOAP 1.2 spec.

That said, a quick grep through the part 1 WD shows don't have section
describing SOAP Extensibility although we do speak of extensions; the
concept of modules seems of have gone - don't rememeber that happening.

Regards

Stuart
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0384.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0387.html
> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: 30 January 2002 13:57
> To: 'noah_mendelsohn@us.ibm.com'; skw@hplb.hpl.hp.com
> Cc: 'Henrik Frystyk Nielsen'; xml-dist-app
> Subject: RE: Resolving the Ed Note in Part 1 section 5.1 (was New
> Issues)
> 
> 
> 
> Folks:
> 
> As I mentioned on yesterday's call, I have some trepidations 
> about this compromise.  Here's the main part I have a problem with:
> 
> > * Architecturally separate application level extensions (using headers) 
> > from binding level "features":  when we say feature, we mean an optional

> > capability implemented by one or more binding specifications. 
> >  >> Features must be defined in terms of non-envelope properties of the 
> > state machines at each node, except that features can make read-only
access to 
> > information in the envelop infoset property.<<
> > 
> > * Eliminate from Stuart's proposal the notion that there are multiple
ways 
> > to provide a feature, and that nodes have discretion in choosing among 
> > them.  Instead, we say that each binding specification implements zero
or 
> > more features.  For any given feature, all bindings that implement the 
> > feature do so compatibly as seen in the state machine (bullet above).
In 
> > other words, the application has a consistent model of how reliable 
> > delivery is requested and achieved, regardless of which 
> > binding is chosen.
> 
> This seems to be rather antithetical to the original purpose 
> of abstracting out "features" in the first place.
> 
> I think it is critical that we have a mechanism to express 
> the semantic equivalence of particular binding-level features 
> that might be provided "natively" and those same features 
> when expressed/implemented in the SOAP envelope.  The ability 
> of a given feature (request-response, say) to be 
> transparently implemented either at the binding layer or as a 
> SOAP module without necessarily impacting the implementation 
> of an application running on a "smart" soap node has always 
> seemed a key goal of the TBTF.
> 
> As I recall, this precise equivalence (for instance, being 
> able to implement the SAME concept of request-response by 
> either using HTTP or SOAP headers over some native one-way 
> protocol) was what we spent an awful lot of time on for the 
> first few months of this group, and I'm very concerned that 
> this continue to be reflected in the framework.
> 
> Personally, I prefer the original text in the spec to this, 
> and prefer Stuart's edits over the spec text.
> 
> In the conversation leading up to this point, it seemed to me 
> that we were all on the same page with respect to the fact 
> that decisions would get made as to how to express particular 
> application-requested features (based on binding 
> capabilities, endpoint descriptions, etc), but there was some 
> disagreement as to "which piece" of the system made those 
> decisions.  Noah was pushing for it being the binding's 
> responsibility, while I felt it was up to the node.  I still 
> think this is a resolvable issue, and would prefer to see a 
> resolution which does not move the framework away from what I 
> perceive to be one of its key features.
> 
> --Glen
>

Received on Thursday, 31 January 2002 08:17:55 UTC