W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

Re: [metaDataInURI-31]: Initial draft finding for public review/c omment.

From: Mark Baker <distobj@acm.org>
Date: Sun, 13 Jul 2003 13:41:00 -0400
To: "Williams, Stuart" <skw@hp.com>
Cc: www-tag@w3.org
Message-ID: <20030713134100.B13757@www.markbaker.ca>

Hi Stuart,

On Fri, Jul 11, 2003 at 04:59:06PM +0100, Williams, Stuart wrote:
> > REST's "hypermedia as the engine of application state" 
> > constraint has relevance here too, I believe.  If an agent is 
> > hardcoded to know about URI structure, and uses this 
> > knowledge to progress through the application state machine, 
> > then it isn't conforming to this REST constraint.
> Understand the first part (hardcoded knowledge of URI structure), understand
> the second part (progression through application state). Don't understand
> the conjuction ("and uses this knowledge to") of the two. Maybe you could
> elaborate if you think it would be worthwhile (and remain on topic).
> >  As an 
> > example of one of problems with doing things this way, though 
> > the resource reachable through this knowledge would have a 
> > URI, Google would have no way of discovering this URI, as it 
> > isn't hardcoded with that same knowledge.
> Sorry... you've probably tried really hard to keep it brief here... but its
> not managing to make sense of it.
> There are probably a load of assumptions buried in "this way".

Say I'm publishing a service that assigns URIs to people, and URIs to
contact information for those people.  If I require that clients of the
service have to know to append "/contact/" to the URI of a person to get
their contact URI, then this is not RESTful.  The RESTful solution would
include the URI for the contact resource in the representation of the

Does that help?

The drawback of the non-RESTful approach described there, is that it
more tightly couples client and server, such that deployment of new
services, or service changes, necessitate client upgrades.  So perhaps
words to the effect of "URI publishers should not require that clients
peek into their URIs in order to progress through the application state
machine" or some-such.  The finding currently looks at URI-peeking from
the consumer POV, but I think that some publisher-targetted advice would
be useful.

> >  Perhaps that 
> > should go in section 1.1?  BTW, the constraint is discussed 
> > most directly (AFAICT), briefly in section 5.3.3 of Roy's 
> > dissertation;
> > 
> >
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
> _3_3
> Will take another look.

(BTW, I was referring to the last paragraph)

> > The only other issue that I felt required mention, was that I 
> > believe the statements in sections 2.1 and 3.1 regarding 
> > constraining the type of resource that a scheme can identify, 
> > are incorrect; a URI scheme cannot constrain the kind of 
> > resource a URI in that scheme identifies.
> I think it's a question of conforming to standards/specifications. If a spec
> imposes a constraint that you ignore then you are not conforming to the
> spec.

I don't believe that interoperability is affected if I claim that
"mailto:distobj@acm.org" identifies my person rather than my mailbox,
so I claim it isn't necessary for the scheme to suggest otherwise by
using MUST (or even SHOULD) semantics.

> I think that the point is arguable. You have certainly used a mailto URI to
> indirectly identify yourself... but if you want to make assertions about the
> mailbox itself and not about Mark Baker, what identifier would you use if
> you have used up mailto:distobj@acm.org as identifying you.

I reckon I wouldn't.  I didn't say there weren't consequences! 8-)

> > Luckily, I 
> > don't see this issue as key to the point that the finding 
> > addresses, so it should be able to be removed without impact 
> > (or left as is, I suppose - I recognize this may be a rat hole).
> Well looks like I took the bait.

8-)  I'll leave it at that.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Sunday, 13 July 2003 13:35:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:59 UTC