[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Is Resource/Representation a fruitful abstraction? (wasRe:

Re:  Is Resource/Representation a fruitful abstraction? (wasRe:
On Thu, 30 Jan 2003 14:50:49 -0800, Paul Prescod <paul@p...> wrote:

> You said that "resource oriented programming" is unproven as a basis for 
> the Web-as-we-know-it. I admit I only used the context of the one message 
> and not the whole thread (my name floated by...). In my personal opinion, 
> whether one thinks of resources as abstract or concrete, resource 
> oriented programming is fundamental to the Web-as-we-know it. If by 
> "resource oriented programming" you mean something more metaphysical 
> about abstract resources then I won't spend much effort arguing about 
> it...but woudl prefer you use a different term!
> I don't think that there is that much PRACTICAL difference between the 
> two views because best practices will lead people to give concrete 
> representations to otherwise abstract resources, and to NOT use pre- 
> existing concrete URIs to mean something abstract.

OK, I can agree with all that.  I somewhat unfairly loaded "ROP" with the 
metaphysical baggage that we were debating somewhere up this permathread.

> Of course Google doesn't care whether I think that the strings are URLs 
> or URIs, but if Google treats them only as locators and not as 
> identifiers, then it cannot provide its service. A locator is a thing 
> with exactly one operation: "dereference."

I think I'm convinced!  Again, I think I was responding from a mindset 
colored by a different argument somewhere upthread.

> In the realm of services hard-coded to talk to each other, you are 
> entirely right. In the realm of services that are more loosely connected 
> (for instance through pipes and filters), I do not think you are.

I think this is a key point.  Definitely, the more one has to discover 
services on the fly and late-bind to them, the more the principles of the 
Web As We Know it (such as hyperlinks, the ability to leverage Google, ...) 
will be important for Web services people to use and appreciate.  A lot of 
the disconnect between the "Web as We Know It" folks and the "Web services" 
folks is that "discovered-on-the-fly, loosely-coupled services invoked over 
the Web" exist mostly in marketechtures and white papers now. The 
SOAP/WSDL/RPC paradigm works pretty well (at least compared to the easily 
available alternatives) for application integration on secure, highspeed 
LANs, and the people actually doing that stuff resist being lectured to by 

Some interesting dialogues are going to take place when people start 
working in the fuzzy middle where services must be loosely connected to 
each other yet tightly integrated with exisiting back-end systems.  IMHO, 
neither the pure "design everything as a resource and access 
representations over the Web" nor the pure "design everything as an object 
and pretend the Web isn't there" approaches will suffice, so they'll have 
to cross-pollinate each other.


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.