Re: Draft of TAG Submission to W3C Workshop on Web of Services for Enterprise Computing

I understand your concern, and I'll also acknowledge that I probably 
didn't do the best possible job of making the point I had in mind.  I 
really was thinking of use cases where the typical URI would wind up with 
multiple parameters, and in which users would be mixing and matching those 
parameters to create new URIs.  So, if I want to get at the level for the 
non-photo black ink in printer 3 on cluster 2, how are those parameters 
expressed.  Is there a canonical order for them, etc.?  Is there a 
standard description language that will enable an automated tool to help 
be build URIs with the right combinations of parameters in the right 
order, and appropriately represented in path segments and/or query 
strings?  I believe the WSDL 2.0 HTTP binding offers some facilities that 
could be used, but it's still something of a challenge I think.

Anyway, I'll admit that if your comment had come in earlier I probably 
would have done a more effective clarification.  Given the limited time 
available for submission, I mostly left things as they were, but I did 
change the sentence:

"Indeed, use case 2 makes the point that the RESTful approach of assigning 
a URI to every resource can be inconvenient, particularly when large 
numbers of properties with parameterized names would each have to be 
represented in its own URI. "

to

"Indeed, use case 2 makes the point that the RESTful approach of assigning 
a URI to every resource can be inconvenient, particularly when large 
numbers of properties with parameterized names would have to be 
represented in URIs."

The following sentence remains the same is before:

"It's relatively easy to motivate giving the printer its own URI; it's 
somewhat harder to decide whether to also assign a separate URI to each 
paper drawer in the printer, to each part of the printer that can jam, 
etc. Web Services does provide alternatives for addressing such very fine 
grained resources. "

I hope that's at least a small step in the right direction.  Sorry not to 
more completely deal with the issue that you raised.  I do appreciate the 
comment.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Elliotte Harold <elharo@metalab.unc.edu>
Sent by: www-tag-request@w3.org
01/09/2007 02:36 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     www-tag@w3.org
        Subject:        Re: Draft of TAG Submission to W3C Workshop on Web 
of Services for  Enterprise  Computing



Looks good. The only thing I found questionable was the assertion that


Indeed, use case 2 makes the point that the RESTful approach of 
assigning a URI to every resource can be inconvenient, particularly when 
large numbers of properties with parameterized names would each have to 
be represented in its own URI. It's relatively easy to motivate giving 
the printer its own URI; it's somewhat harder to decide whether to also 
assign a separate URI to each paper drawer in the printer, to each part 
of the printer that can jam, etc.


I don't find it hard at all. I do see a lot of systems that are crippled 
by some needless stinginess with URIs. However, I see now reason we 
can't have (for example)

http://laser1.example.com/drawers/1
http://laser1.example.com/trays/legal
http://laser1.example.com/trays/letter
http://laser1.example.com/toner
http://laser1.example.com/queue
http://laser1.example.com/queue/currentjob

etc. You could use query strings instead if you prefer. However, 
especially int he case of a printer, where arbitrary files in arbitrary 
locations are unlikely to be installed, it seems reasonable to make use 
of the path part of the URL for addressing printer parts and features.


-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Received on Wednesday, 10 January 2007 17:40:40 UTC