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

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org] 
> Sent: 13 July 2003 18:41
> To: Williams, Stuart
> Cc: www-tag@w3.org
> Subject: Re: [metaDataInURI-31]: Initial draft finding for 
> public review/c omment.

<snip/>
 
> 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 person.
> 
> Does that help?

Yes, thanks.
 
> 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.

Let's see how the next rev. turns out... I'll try to work it in. At least
last time we (the TAG) discussed this issue there was some bias toward a
very short finding centred on "don't peek..." so great chunks may disappear.

<snip/>

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

You might make statements about mailto:distobj@acm.org that are about
yourself. Someone else (me for instance) might make statements about
mailto:distobj@acm.org that are about a mailbox, or they might interpret the
statements you made as being about a mailbox. That seems like an interop
issue to me.

That said, we could take the position that web clients should not infer
anything more than syntactic constraints (narrowing constraints on
2396(bis)) from the scheme name component of a URI. Then we are just making
statements about a resource, even though you and I might have very different
resources in mind for whatever mailto:distobj@acm.org identifies - you are
consistent in your usage, I am consistent in mine - our respective uses are
inconsistent, but that's just life and it could happen with any identifier.

I think that there are folks wanting to build systems that contain rules
base on URI scheme components. Taking a position that says URI schemes can
indicate the sort of thing they were intended to identify, but they cannot
constrain there usage to just those things means systems cannot safely make
inferences based on contents URI scheme components (or URN NSIDs...). They
would have to go elsewhere to get information about a resource.

BTW: where do I find machine readable authoritative information about
"mailto:distobj@acm.org"?

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

Stuart
--

Received on Monday, 14 July 2003 08:02:59 UTC