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

Comments on WebArch

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 23 Feb 2004 11:40:00 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA202B06D8A@RED-MSG-30.redmond.corp.microsoft.com>
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

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

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