Re: Web-friendly SOAP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/24/2002 1:04 AM, "Paul Prescod" <paul@prescod.net> wrote:

> 
> Walden Mathews wrote:
>> 
>> ....
>>> but any node that can't
>>> download data from
>>> the Web using HTTP isn't really on the Web and should not expect to
>>> share in the benefits OF the Web.
>> 
>> This just seems like defining "Web" in terms of HTTP, or is it saying
>> something deeper?  I'll read the abstract before posing any more
>> foolish questions.
> 
> No, nothing foolish about the question. I would say that one of the
> defining characteristics of the Web is that it is a *web of links*. That
> means that any document may refer to any other document with a URI and
> there is some clear way to turn that URI into some information. So no,
> I'm not defining the web in terms of HTTP. FTP also has that property.
> news: also has that property. My point is that its all very well and
> good for me to shoot a short XML document over some future HTTP on UDP
> and not expect a response. But the recipient will often need to use the
> old-fashioned HTTP request-response message exchange pattern in order to
> retrieve information referenced by the XML I sent. Consider the simplest
> case:
> 
> <foo>
> <xi:xinclude href="...."/>
> </foo>
> 
> Of course some applications may choose to forgo the use of URIs (as it
> seems, for instance, that ICE does) but those applications are giving up
> the best part of the Web. Why use HTTP if you're not going to benefit
> from the fact that the Web is a *web of links*?

Just to clarify one point: ICE does use URI's for external references. For
example, if I send a package that includes two files by reference, I send
(pseudo-XML):

<ice-package ...>
   <ice-item-ref subscription-element="2001"
        url="http://server/path"/>
   <ice-item-ref subscription-element="2002"
        url="ftp://username@serve/path"/>
</ice-package>

Part of the semantics of receiving the package is receiving the files
referenced within the update, using the request/response semantics you've
described. So when you confirm delivery of the content, that means that
you've retrieved all external files that are logically included in the
package by reference.

ICE also uses URI's as the addresses of endpoints. So if I am syndicator
"8712731271389" (GUID), I also tell people that my address is (for example)
"http://ice.foocorp.com". The two are distinct because I could retain my
identity while changing my address. :-)

Where ICE doesn't use URI's is for internal identifiers. For example, every
item within a subscription can have a permanent ID that is used for
deletion and overwriting. For example, if I wanted to delete item 2001 from
the subscription, I would send:

<ice-package ...>
   <ice-item-remove subscription-element="2001"/>
</ice-package>

While identifiers such as subscription-element could be URI's, they aren't
required to be, because they don't need to be (and because very often the
obvious implementation would be a database-generated sequence number).

So what this all comes down to is that ICE does, in fact, assume that all
participants can resolve URI's for all things that are externally
referenceable. I'm sorry that my earlier explanation caused some confusion
on that point.

- - Laird Popkin

> Paul Prescod
> 

- -- 



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE9FsjI4+IiU0KDOA4RAmkQAJ9aXO8uoKS8FAcvIgdRz/Pz78/DywCfQhO+
0c1397DDcHG/fUArdEinraw=
=Fgl3
-----END PGP SIGNATURE-----

Received on Monday, 24 June 2002 03:23:15 UTC