<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hi all,<DIV><BR class="khtml-block-placeholder"></DIV><DIV>Just a quick reply to this post:</DIV><DIV><BR><DIV><DIV>On Oct 25, 2005, at 9:26 PM, Dr. Ernie Prabhakar wrote:</DIV><DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Yeah, I have concerns too if this is the proposal.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>To be precise, this is "a" proposal. Others are welcome, and probably needed. However, this is intended to be the *simplest* possible encoding, to use as a starting point.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The biggest problem is that HTML over HTTP is already RESTful. Every web page with a form is already a self-descriptive hypertext document on how to compose</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the request.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sure, but not all HTML is a web service. Certainly not all HTML can be trivially parsed to extract out the semantically meaningful URIs.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>1. Constraining REST verbs to POST/GET</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">As for restricting to POST/GET, that's the wrong direction to be moving</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in, just look at Web Forms 2.0[1] for what's coming in the next version</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">of HTML.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Great! I'd love to have more semantics to work with. Unfortunately, the goal of *this* encoding is finding something that works with today's browsers. The necessarily implies a *subset* of REST functionality, which may be not be appropriate for all uses.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>You're welcome (even encouraged) to propose something that will work better in the future; I'm worried about doing something that works today...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>2. A system for constructing URLs.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">There are already several systems for construction URLs</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>That's my point. :-) With HTML, there's only one, which is a useful constraint.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>3. Discovery through URL construction as opposed to hypermedia.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Hypertext as the engine of application state is an important</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">concept, one I've written an entire article on [3].</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">[3] <A href="http://www.xml.com/pub/a/2005/04/06/restful.html">http://www.xml.com/pub/a/2005/04/06/restful.html</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm not sure I understand, but I think we're in violent agreement. I am arguing for a *convention* on how to interpret URLs, so human's can more readily understand them. I agree the system itself should not hard-code specific URL interpretations.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN>4. Limiting transfer representations to application/x-www-form-urlencoded</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I'm not gonna really comment on that except to point out that</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">uploading a video encoded in application/x-www-form-urlencoded</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is going to be a bit wasteful.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>That was a red herring: of course browses support mime multi-part, so REX should too.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I've got my own ideas about how microformats intersect</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">with RESTful web services that I've outlined in [4],</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in general seeing everything through my Atom colored</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">glasses.</DIV></BLOCKQUOTE><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">[4] <A href="http://bitworking.org/news/What_do_you_see_in_Web_2_0_">http://bitworking.org/news/What_do_you_see_in_Web_2_0_</A></DIV></BLOCKQUOTE><BR></DIV><DIV>So, if I understand you correctly, you're arguing for applying microformat principles to Atom, and using that as the generic carrier for web services?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I don't have anything against that, but I'm unclear on what (if any) advantage that has over using XOXO/XHTML as the carrier. Especially since, much as I like Atom, I don't see it nearly as widely deployed (much less readable) than HTML.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If there's something specific you can do in Atom I can't do in XOXO, I'd love to find out what that is, so I know where my boundary conditions are.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Thanks,</DIV><DIV>-- Ernie P.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>------------ </DIV><DIV>Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org></DIV><DIV>Ex-Physicist, Marketing Weenie, and Dilettante Hacker</DIV><DIV>Probe-Hacker blog: <A href="http://www.opendarwin.org/~drernie/">http://www.opendarwin.org/~drernie/</A></DIV></SPAN></DIV></DIV></DIV></BODY></HTML>