Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Did Documents Win? No. Objects Just Couldn't GetTheir Ac
 On Fri, 2006-02-24 at 14:41, Bullard, Claude L (Len) wrote: > Agreed. If the network definitions are semantically simple, > the communications load is in the resource definitions and > negotiations of the meaning of signs (from a semiotic perspective). > > I think it comes down to explaining that network definitions > (verbs for schlepping stuff) are never *meaningful*. It's like > asking your mailman to do your taxes instead of moving the > form to the IRS and bringing the payment back. (We may have some > fun later merging this thread into Pragmatics (not what > Box is talking about but the subfield of linguistics)). This is more along the lines of what I was talking about. I wasn't trying to imply that naming was easy. I was more referring to the classification of something which is chosen to expose it via a REST interface--specifically in the context of a complex application which was beyond the bounds of something like an order, a tree, a bird, a human, web page, etc. What I needed was to kinda stand back and squint at my particular problem to figure out how to classify something that could have been looked at from a number of perspectives, because I thought the obvious choice was too fuzzy a concept to sensibly represent via the standard HTTP verbs. It was more of a mechanism or process, rather than your typical resource. Actually, in this particular case, the naming was easy, but figuring out something sensible that the name represented and would play by the rules (POST/PUT/GET/DELETE) was difficult. In the end it took two abstractions: the mechanism and something else which was really there just to support the access semantics. In Len's example above, which is most important: who you ask, or what you're asking them to do for you? In one scenario (security and trust issues aside), you could say you wanted to pay your taxes because that's the abstraction you were using. If your postman accepted your box of receipts, knew to take them to your account who would then prepare your tax return for you and then deliver it to the IRS, you *could* logically ask your postman to do your taxes--even though that's not his job. Of course, knowing that your postman could do this (or that he even was a postman, really) brings you back to your semantics vs. pragmatics point. > > Why Federated instead of Confederated? In other words, if > REST is Federated naming, you are saying it is centrally > administered. I'd say it is Confederated because the > meaningful names are in the packages, not the types of > the envelopes. I have to agree with this as well. The access to the package is the same, but you don't know what it is until you look at the manifest. Factor in security policies, and you can't always look at the manifest (or even see the package). Again, I'm thinking about this in more of an application-specific view rather than specifically in the context of the web. Of course, I can see how Peter's recursion argument comes into play here as well: "if I had an Index File, I could look up how to find the index file under 'Index File'!" (for the Dr. Who fans out there). ast > > From: Richard Salz [mailto:rsalz@u...] > > > But I think the hardest thing to understand about REST isn't the > > semantics of the operations per se, but how exactly to define what the > > resource is so that the operations make sense. > > Yes, naming in distributed systems has long been recognized as a a very > important, subtle, and hard problem. > > I used to say REST is just federated naming, but nobody understood me. *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
