W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

Future resources

From: Mark Baker <distobj@acm.org>
Date: Wed, 19 Feb 2003 00:37:30 -0500
To: Geoff Arnold <Geoff.Arnold@Sun.COM>
Cc: www-ws-arch@w3.org
Message-ID: <20030219003730.S19708@www.markbaker.ca>

We're getting off-topic here, but you raise an important point that I'd
like to respond to.

On Tue, Feb 18, 2003 at 11:28:10PM -0500, Geoff Arnold wrote:
> It's worse than that,

BTW, to Chris' response, that knowledge he speaks of is no different
than the knowledge required to know that turnOn() is implemented, or
that "1" means "on" and "0" means "off".  The win is in the common
PUT method, instead of the cornucopia of turnOn(), switchOn(), on(),
foofoo(), etc.. methods.

> because of composition. Consider the composite
> action "PlugInNewLightbulb THEN TurnOnLightbulb". Not only do we have
> to handle partial failures; one cannot even *express* the desired state
> of the new bulb as a state-representation PUT, because it doesn't exist
> until the first part of the action is complete.

Not at all.  The bulb doesn't have to be chosen to have a URI.  I could
mint a URI that identifies "the bulb that will be chosen during
PlugInNewLightbulb", long before its chosen, without any trouble.  It
does, after all, have identity.

The URI would likely resolve to 404 at mint-time, and 301 once a URI for
the less indirect reference to the light bulb is known.  There's no
problem with this.  Indeed, it's a key feature of the architecture,
since to require otherwise is to ban 404s and require some degree of
centralized control, as some previous (long-forgotten) hypertext systems

Unfortunately, while this topic is very relevant to the TAG's
architecture document, it's probably irrelevant to ours, unless of
course we adopt REST. 8-) So I suggest we take this off-line, perhaps to

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Wednesday, 19 February 2003 00:34:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC