Re: A proposal for supporting property binding

Dear Youenn,

Ah, now I understand.

This seems to me very similar to the comment made earlier by Robin Berjon.  Most of the proposal that I have supplied is concerned with binding abstract properties, rather than constraints on abstract properties.

In other words, the proposals currently on the table suggest a syntax for describing the location for storage of particular abstract properties for a particular service operating over a particular protocol.

Protocol documents (such as the email binding) may establish additional constraints on abstract properties that they require, just as they may establish fixed or default storage locations.  Currently at issue in discussions with Chris Ferris, Jean-Jacques Moreau, and Glen Daniels is the question of whether a service ought to be able to override protocol-suggested storage locations.  This proposal addresses value-space constraints, and suggests that while a protocol may provide additional constraints on a value space, a service ought to be able to add to those constraints.

To take your example, a security signature feature might describe the algorithm as xs:string.  A protocol binding might further constrain this to an enumeration, as in your example.  A particular service, however, may support only one of the algorithms listed, so it could redefine the content, allowing only one of these values.

Robin Berjon's example had to do with compression over HTTP.  By the same token, it could be represented with a compression feature, for which the algorithm was of the form "xs:string".  Bound to HTTP, the storage location might be fixed (protocolHeader Content-Encoding), with a set of enumerated values taken from RFC 2616 (are they in there?  I haven't checked), including zip, gzip, compress.  A service could then further constrain, by reducing the enumeration to only gzip (or gzip and the empty string, to indicate that uncompressed messages are also accepted?).

I agree that this seems useful.  It isn't something that I had considered, but it seems to me that it parallels, in value-space constraints, the current proposal's flexibility to redefine storage location constraints.

Would you like to provide a modification to the document that I produced?  Or would you like me to add such a thing?  It seems to me that it could be integrated fairly comfortably into that proposal (and would remove the item, under issues, raised by Robin Berjon, perhaps).

Amy!
On Mon, 04 Nov 2002 17:24:51 +0100
"FABLET Youenn" <fablet@crf.canon.fr> wrote:

> >
> >
> >On reviewing the proposed outline (in your original response, which set
> >forth a schema-pattern for these things), so that the email binding
> >could use that model, I discovered the property definition section.  I
> >think that these are not necessary; only bindings of properties are
> >necessary, their characterization in XML is not.  I can expound on that
> >if you wish (it took more senior architects here a couple of days to
> >convince me that an XML description of a feature, while possible, is
> >either superfluous or insufficient, but that seems to be the case).
> >
> 
> I am not sure exactly why  there is no good in a characterization of 
> properties in XML/XML-Schema.
> I agree that it is not feasible to build a parser that will implement a 
> feature from an xml description.
> However an xml description of a feature might be useful for other 
> purposes: it allows for instance to say how are implemented features.
> Let's have a signature feature with an algorithm property. This property 
> tells the server which algorithm (SHA/RSA, MD5/RSA....) to use in the 
> signature process. It might be useful for the server to advertise which 
> algorithms it supports.
> A general xml description of the algorithm property would be for instance
> <property name="algorithm" xsi:type="xsd:string"/>
> There is no "useful" information in this description since the client 
> has to implement this feature to use it..
> The xml description of the server would be something like:
>     <property name="algorithm">
>         <xsd:restriction base="xsd:string">
>             <xsd:enumeration value="SHA/RSA"/>
>             <xsd:enumeration value="MD5/DSA"/>
>         </xsd:restriction>
>     </property>
> In this case, the server clearly indicates how to use the feature (I 
> understand SHA/RSA and MD5/DSA signatures).
> An xml description of a feature is therefore useful when using a subset 
> of a feature and /or when using an extensible feature.
> Schema validation tools can test whether the values that are assigned to 
> features in the wsdl file are allowed by these features.
> It is also interesting to note that feature schemas are already almost 
> written for most of (all ?) known features. Why not reusing them ?
> 
> Also to be noted that this mechanism (plus the use of a wsdl:protocol 
> element that is referenced from the wsdl:binding) can be useful for 
> interoperability purposes: an organisation  can produce an XML profile/a 
> protocol description with all the necessary features that must be 
> supported plus the way they must be implemented (like use HTTP + support 
> feature FOO + the property POO of FOO must have one of these values...)
> 
>     Youenn
> 
> 
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 5 November 2002 13:39:46 UTC