Re: A proposal for supporting property binding

Amelia A. Lewis wrote:

>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.
>
I agree

>
>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.
>  
>
Yes

>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).
>
I do not know how well it will fit in the current proposal (hopefully 
easily ;o).
I'll try to give a thought before next telcon and update your proposal 
accordingly (not sure I will have time however...).

    Youenn

Received on Wednesday, 6 November 2002 04:55:35 UTC