- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 23 Feb 2004 11:40:00 -0800
- To: <www-ws-desc@w3.org>
I finally made it all the way through the Web Architecture document [1] , and don't see anything that outright conflicts with what we're doing in WSDL. In particular, we have good strategies many things the Arch document calls out as good, like Versioning and Extensibility of the WSDL language itself. Here are my notes on things we may want to take into consideration as we complete our spec. [1] http://www.w3.org/TR/2003/WD-webarch-20031209/ 1.1.3: "Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role to which of its principles could guide their design: statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs." WSDL describes higher-level protocols. Do we need to give corresponding advice to WSDL users? 1.2.2: "Clearly, creating an extension language is better for interoperability than creating an incompatible language." I note that we didn't do that with WSDL :-(. 1.2.3: "Principle: Error recovery. Silent recovery from error is harmful." Could this conflict with the ability to only use a part of a document that does not contain errors, without flagging errors in other parts of the document? 2: "It follows that a resource should be assigned a URI if a third party might reasonably want to link to it, make or refute assertions about it, retrieve or cache a representation of it, include all or part of it by reference into another representation, annotate it, or perform other operations on it." We make target namespaces and component designators available as URIs, as well as styles, features, properties. Are there other things that should be identified by URI? 2.1: "The most straightforward way of establishing that two parties are referring to the same Web resource is to compare, as character strings, the URIs they are using." Double-check that we have a URI-comparison algorithm in place for any URIs we need to compare. Double-check our use of relative URIs is reasonable and consistent. 3.3.1: "Note that one can use a URI with a fragment identifier even if one does not have a representation available for interpreting the fragment identifier (one can compare two such URIs, for example). Parties that draw conclusions about the interpretation of a fragment identifier without retrieving a representation do so at their own risk; such interpretations are not authoritative." This seems to imply that you can compare component designators, but you can't safely crack the URI and infer (for example) the type of component from it. Do we need to say anything about that? 3.5. "Safe Interactions" Relates to our operation safety issue, but doesn't cause proposals to spring immediately to mind. 3.6.1: "Good practice: Available representation - Publishers of a URI SHOULD provide representations of the identified resource." We pass this advice on to WDSL authors (targetNamespace) and feature/extension authors, but do we also need to post docs at each of our feature and style URIs? 4.2.2: "Good practice: Namespace policy - Format designers SHOULD document change policies for XML namespaces." Relates to our versioning issue: How do we allow WSDL users to communicate the change policies for their namespaces (even though they aren't strictly XML namespaces)?
Received on Monday, 23 February 2004 14:40:11 UTC