- From: FABLET Youenn <fablet@crf.canon.fr>
- Date: Mon, 04 Nov 2002 17:24:51 +0100
- To: Amelia A Lewis <alewis@tibco.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>
- CC: www-ws-desc@w3.org
> > >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
Received on Monday, 4 November 2002 11:25:43 UTC