- From: Paul Prescod <paul@prescod.net>
- Date: Mon, 08 Jul 2002 10:34:43 -0700
- To: Eugene Kuznetsov <eugene@datapower.com>
- CC: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, xml-dist-app@w3.org
Eugene Kuznetsov wrote: > > ... > > I think one difference is that XML & XHTML can be part of the > same world, consumed by the same clients. The whole point of > HTML, content-negotiation and browsers gracefully falling back > to LCD is that the consumers are the same -- so the nature of > layering is important. To use the <P> example, you could have > something like <P author="john"> and <P author="joe">, and all > browsers could still make sense of it -- and some could take > advantage of the "author" attribute. This kind of extensibility > is important. This kind of extensibility is known in the Web architecture as "Partial Understanding". e.g. "http://www.wired.com/news/technology/0,1282,11693,00.html Partial understanding is a core component of all interoperable software development. Very seldom do components know the full scope of their environments. Rather they know just enough to get their jobs done. > However, the target for HTTP-transported web services isn't > the same as HTML browsers. It's a bit like streaming video > -- OK, yes, you can transport it over HTTP, but it requires > totally different functionality and there's no graceful > 'fallback' for an HTML-only browser -- but even more so, where All good, interoperable, extensible network software is designed to work with partial understanding. Your mail client probably does not understand every header in the current message. It understands enough to do its job. Other intermediaries understand other bits. If you do not tunnel, you allow HTTP-knowledgable software components to do their job: * Squid can cache based on URIs, method names and cache headers * Spiders can walk through the resource graph looking for information relevant to them * Service containers can implement recursive deletes of resource hierarchies (with WebDAV) * Load balancers can do balancing based on URIs * Resources can be retrieved for basic processing with "wget" and replaced with "curl" * Internet Explorer can graphically display resource representations (probably using <?xml-stylesheet ...?>) * Windows Explorer can graphically allow the browsing, moving, deleting, etc. of resources * Any resource may refer to any resource, anywhere in the universe using only URIs * You can use Apache to help dispatch messages to the appropriate resources * Apache can do "redirects" when resources are moved or merged * Any resource may incorporate information from any other resource by reference using XPointer, XLink, etc. * Any resource may be annotated with metadata either through WebDAV or RDF or both. Okay, Squid does not know that the GET means "GET purchase order" but it knows how to cache gets. Windows Explorer does not know that "DELETE" of a travel itinerary means "cancel trip" but it knows how to delete (it doesn't REALLY know what it is deleting even in the local case). Your RDF engine does not know why you are adding metadata or what the annotations mean. Your XSLT engine doesn't know that following a link fetches a user's address. But they doesn't need to know everything. Neither does your SQL engine understand that an UPDATE to the "purchase orders" table means add a purchase order. It just knows the semantics of the SQL specification as Apache knows the semantics of the HTTP specification. Your application layer semantics can be expressed *in the data*, not the operation names. > at least with HTML & video you still have a person consuming > the data, but with web services it's a server-to-server comlink. I think that we can do much better than a "comlink". Interoperability requires a more globally shared understanding of the universe. Web architecture provides that. If you think of the universe as being composed of addressable, mutable, active resources, you can get much more interoperability than if you think of the universe being composed of nodes that only know how to "SEND" and "RECEIVE" (which is basically the "message-oriented" view that people are so anxious to tunnel on top of HTTP). We are in a big hurry to give up the high level of practical, workable interoperability possible with tools that exist today in favour of the shibboleth of protocol independence. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Received on Monday, 8 July 2002 13:35:24 UTC