W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

Re: Comments on WebArch

From: Jacek Kopecky <jacek.kopecky@systinet.com>
Date: Tue, 24 Feb 2004 14:11:08 +0100
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1077628268.8180.171.camel@localhost>

Jonathan, some responses interleaved below. 

On Mon, 2004-02-23 at 20:40, Jonathan Marsh wrote:
> 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?

If anything, I think our advice should be in the form of: WSDL describes
Web Services, for architectural principles see WS Architecture doc and
AWWW doc.

> 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 :-(.

Only applicable in situations where such an approach is actually
feasible. 8-)

> 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?

We don't say that when a processor encounters an error, it may try to
recover silently. What we say is a processor may not traverse some parts
of a document and therefore not detect any errors in it. No conflict.

> 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?

Cracking WSDL component designator URIs is only suitable when the
representation of the resource is WSDL. Constructing WSDL component
designator URIs is no problem as long as the spec says precisely and
normatively how that's done.

DaveO's example of cracking a URI when somebody tells me it is a WSDL
component designator URI is probably OK, too, although from the
perspective of the Web it may not be authoritative.

> 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?

I think we do.

> 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)?

If the namespace document is a WSDL, documentation elements may contain
any change policy information. I don't think a core version attribute
would be particularly helpful here because the documentation can point
at any extensibility attribute on any element and say what kind of
version information it contains.

Received on Tuesday, 24 February 2004 08:11:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:38 UTC