RE: Features and Properties versus Extensions

Hi David: 

Sorry for the delay in responding to this.

> I wanted to ask some clarifying questions about features and 
> properties as I don't think I'm understanding them very well.  
> I thought about how a developer/user could use them in the 
> http properties work I did, and I couldn't quite get to closure.

Cool, great stuff!  My take on it is below.

> Imagine that I create a property "httpauthentication", and I 
> then adorn this property in a couple of http binding 
> operations and a binding.  Let's pick a simple example with a 
> shorthand for setting the value.
> <binding>
>   <property name="httpauthentication" value="basic"/>
>   <operation name="op1">
>      <property name="httpauthentication" value="digest"/>
>   </operation>
>   <operation name="op2">
>      <property name="httpauthentication" value="digest"/>
>   </operation>
>   <operation name="op3"/>
> </binding>

OK, gotcha.

> My main question is, what kind of expression do I use to get 
> the value of the httpauthentication in the various bindings?  
> Say I'm a consumer and I want to find out what HTTP 
> authentication algorithm needs to be used to communicate with 
> the service.  If I use XPath, I have to get the value of the 
> property element with the name=httpauthentication, ie 
> "/binding/operation[@name="op2"]/property[@name="httpauthentic
> ation]/value. If it doesn't exist, then I have to follow the 
> f&p algorithm, ie go up the tree.   

From a purely XML-centric point of view, that's correct.  I'll quickly
make my main point here, then comment some more below - WSDL has a
component model which is different from the XML that serializes it, and
F&P are only one aspect of this difference.  For instance, in the WSDL
component model, a derived interface has access to all the operations
from its parent interface(s) as well as the ones directly inside the
derived one.  So you would need to do exactly the same thing (i.e.
follow the WSDL inheritance algorithm) to find any operation in a parent
interface from the derived one.

> It seems to me that this is a new data model layered on top 
> of the XML data model, and I'd probably actually want a new 
> query language for it or at least an xpath function.  What 
> I'd really like is to ask "get the property with 
> name=httpauthentication in the binding element and follow the 
> f&p rules to generate it".  Something like 
> "property[@name="httpauthentication"]/binding/operation[@name=
> "op2"" where the property function evaluates the name in the 
> context that it is given.
> 
> Is this roughly right?

I think this is perhaps an interesting direction to think about, but
certainly not necessary to make the model useful.  WSDL itself, as many
application dialects are, seems to be "a new data model layered on top
of the XML data model", no?

> Secondly, it seems that you would really need this new 
> function to reasonably use features and properties.  This 
> would also help to do conformance testing.  You could test 
> whether the properties were correctly set would be to have 
> some kind of function to use them.  I think that this is 
> somewhat related to the issues that Schema and Query did, 
> which is to have the query language layered on top of the 
> schema language.  And fwiw, I'm not sure that was the right 
> decision given how many problems that Query has had with 
> Schema.  It seems very difficult to define the data model 
> without defining the query language on the data model.  
> 
> Has there been any talk about doing this?

Not that I know of.  I don't believe that you really need a new specific
language for manipulating and navigating F&P for it to be useful - any
more than you do for manipulating the WSDL data model.  The point of a
WSDL document is to represent a serialization of something that is
useful at runtime.  The WSDL component model (which includes F&P) is not
the same as the XML data model of the document, and I don't think it's
necessary to introduce new techniques for explicitly navigating any part
of that model at this time (though we might want to later).

> Do setting of properties replace duplicate properties, as I'm 
> showing in the case of digest replacing basic, or are they 
> composable in any way? 

The rule we settled on after some discussion is that more-tightly-scoped
values replace the values from further-out scopes.  I think that
enabling some richer model of composition would be an interesting place
to go, but we haven't broached it yet for simplicity's sake.  This is a
really interesting and important question.

> In the notion that properties have a tree structure, are 
> there scenarios where the "parent" function would be needed?  
> The property  tree structure doesn't directly map onto the 
> WSDL tree structure, so it could be useful to go "up" the 
> tree via properties rather than via the wsdl tree structure.  
> Something like "what's the value of the parent of the binding 
> operation".  Has this been talked about?

Nope.  In terms of defining an actual function "parent()", I don't think
we need to go there, but we *do* need to be crystal clear about what the
scoping rules are.  We've got a start at that already but I suspect it
may need a little tweaking to make sure we express things cleanly
enough.

> In the case of the HTTP authentication, I thought about the 
> advantages of using f&p rather than wsdl extensions.  I tried 
> really hard, and squinted my eyes a lot, but I couldn't see 
> the advantages to using fp.  There is a potentially nice 
> feature that I could express that a value for http 
> authentication is required in the binding operation, but I 
> had a couple of questions on that.

That kind of thing is not, as yet, intended.  See below.

> The ability to specify a constraint in a property seems 
> similar to XML Schema minOccurs="1" functionality but done at 
> runtime on the property component model.  Is this roughly right?
>
> Now, let's say I used the constraint.  If I'm a WSDL author 
> and I put the required in the binding, then I want to make 
> sure that the binding operations set the value.  Presumably I 
> would do some kind of "propertyValidation" step on the WSDL 
> document to ensure that all the required properties were set. 
>  Is this PropertyValidate() function what people are thinking of?

Hm.  No, I think your rabbit hole goes in a slightly different direction
here. :)  The property values are actually *set* by the runtime, through
some mechanism which we do not specify.  If you give a particular value
for a property in WSDL, the understanding is that that value will be
used at runtime, but if there is a constraint, we don't say anything
about how the runtime should perform the validation you discuss.  For
instance, I might pop up a dialog box to my user (at stub-generation or
at runtime) which says "which of these two valid ciphers would you like
to use for encryption?", or alternately I might indicate at
stub-generation time that to proceed successfully, some kind of
configuration is required to set the given property (maybe I get two
commented-out lines of code in my stub that set the cipher property each
possible way).  The actual method for choosing amongst the valid
constrained values is an implementation detail - think policy, which has
the exact same kind of semantic, or even schema, which allows you to
constrain XML values inside messages which are ultimately set by some
runtime code.

> Now going further down the rabbit hole, I have my 
> propertyValidate() function.  I'd expect that the 
> propertyValidate() function would fluff up the property 
> component model that my propertyEvaluate() Xpath would use.  
> This is exactly the way that Schema Validation results in a 
> PSVI that can be XQueried/Xpathed against.  Which leads me to 
> the question about what the Post Property Valid Infoset 
> (PPVI) looks like.  I'd expect that it would need to have the 
> same kind of PSVI stuff like outcomes, ie "required property 
> not available".  Where are we at on the thinking of the data 
> model for the PPVI?

IMHO, the way you do this kind of thing is up to the implementation.  We
could discuss some kind of more explicit WSDL query language later, but
I'm not positive we need to go there at all.

> This message might come across as an attack on features and 
> properties, but it really isn't intended that way.  I'm 
> asking the same hard questions that were asked of the XML 
> data model that have resulted in XPath, Xquery, Schema, PSVI, 
> etc.  These are all tied together and dependent.  In the XML 
> activity, we knew about the problems of not having the query 
> functions for XML Schema and we knew that we'd create a 
> working group for this.

Sure.  See below.

> Now maybe y'all don't agree with the analogy that I'm drawing 
> between XML and Features and Properties, or maybe the need 
> for functions, validation models, PPVI, etc.  And that would 
> be useful for me to know.

Yup, I don't particularly agree with the analogy you're drawing.  F&P
are part of the WSDL component model, which itself, like many other uses
of XML, implies a data model, semantics and relationships which go
beyond that of what's in the XML itself.  Without being an expert in
XQuery or the deeper parts of Schema, I believe that those models relate
to the structure of the XML (for purposes of validation and search), not
the structure of higher-level models serialized as XML, although of
course you can write custom XQuery to navigate your particular data
model.  Does that jibe with your understanding?

--Glen

Received on Sunday, 16 May 2004 22:44:57 UTC