Re: [xml-dev] What are Web Services for? (Was RE: [xml-dev] lots of WS reading material)

Matthew Gertner wrote:
> 
>...
> 
> It's interesting that the thread about XML documents vs. infoset is running
> in parallel. To me these discussions are very close. What makes XML magical
> is actually extremely subtle, and tied up in the fact that it uses a text
> representation, as some have pointed out. The same is true for REST vs.
> SOAP. They accomplish basically the same things, but the nature of the
> implementation actually makes REST far more powerful. The reason, as far as
> I can see, is related to network effects. When you can do a lot of things
> usefully with something, then its value goes up exponentially.

Bingo. Another monk achieves Zen.

> I also think that the case of RDF is analogous to that of the SOAP. The
> underlying idea (providing metadata for resources) is very powerful. But RDF
> doesn't let you leverage the "other" things you can do with XML as well as
> alternative approaches could.

Possibly, but bear in mind that there is a distinction between RDF
syntax and model. The RDF people probably have to figure out how to
allow ANY arbitrary XML syntax to be mapped into the RDF model. Then it
won't be a choice between XML features and RDF features.

> > In that particular case the resources happen to be read-only. They could
> > be read-write, for instance, if it were possible to PUT a new
> > representation of a cached page so that Google's cache and index would
> > always be up-to-date. (of course there are security implications there
> > but you get the idea!!!)
> 
> Still less convinced by this. I don't know many cases of PUT being used to
> change resources. Maybe I am still in the dark ages, but most cases I've
> seen used POST in a controlled way to change server data.

The point is that the application can be read-write. If the "write" you
want to do has the semantic of PUT then it makes sense to use PUT for
clarity and perhaps to achieve some network effects relating to caching.

> > I think it will depend too much on the technical competence of readers
> > to make much money. Remember the blinking 12:00 on the VCRs. People will
> > put up with a lot of hassle to avoid learning something technically new
> > (unless it can be learned in a VERY incremental way).
> 
> Hmmm, maybe this is the answer to the question of how Yahoo can make money
> in the post-advertising age. Offering a service that lets users consolidate
> data from various sources in a user-friendly way could be a money spinner if
> Yahoo (or AOL or MSN or whoever) pays the information providers and charges
> users a flat monthly rate.

I am still skeptical that information can be really *integrated* (as
opposed to just aggregated) in a user interface that the average user
will like enough to pay for.

 Paul Prescod