[
Lists Home |
Date Index |
Thread Index
]
"Roger L. Costello" wrote:
>
> I am just ramping up on REST. Please forgive me if my
> questions/comments are naive.
Roger, detailed discussion should be redirected to the rest-discuss list
because people on xml-dev are tired of the repitition that arises from
teaching REST to new people as they become interested in it.
>...
> Now consider the case where web sites serve up XML not HTML (I shall
> refer to this as XML-REST). Suppose that the XML is programmatically
> processed. The HTTP methods (GET, POST, PUT, etc) provide a nice set of
> **access methods** for getting and putting the XML data. Thus,
> **accessibility** is scalable as it is on the order of linear. However,
> **processing** the XML data still needs customized code (just like
> machine processing of HTML requires custom code). I therefore conclude
> that XML-REST is no more scalable than SOAP.
Yes, this is an important insight. But the linear factor is also
important. I believe that it is much easier to standardize XML
vocabularies within and between industries than it is to share APIs or
messaging interfaces or whatever you want to call them. HTML is merely
an extreme example of this. The widespread success of RSS is a second
example. (might be interesting to try to understand why RSS is so much
more popular on the "public Internet" than is XMLNews...) Obviously
"chemical ML" is going to be much less widespread than HTML but I have
much more hope that Bayer and 3M would share "chemical ML" than that
they would agree on a wire-protocol for describing chemicals. There are
a variety of reasons but one reason is that agreeing on a wire-protocol
is much closer to agreeing on a *business model* than is agreeing on an
XML vocabulary.
>...
>
> How can we make XML-REST scalable? One solution would be to require
> every web site to serve up the same type of XML documents, i.e., have a
> universal Schema that all XML documents conform to. Obviously this is
> not a very attractive solution. The other solution is to have web sites
> serve up documents whose meaning can be dynamically "discovered". I
> believe that RDF is the only XML technology that enables dynamic
> understanding of content. Thus, the cornerstone for a scalable,
> machine-processable web services architecture is:
>
> 1. The HTTP access methods - GET, POST, PUT, etc
> 2. A dynamically understandable vocabulary, such as RDF.
Yes, this is the approach Mark Baker takes. As I am not (yet?) an RDF
"believer" I see it more as a spectrum: as we understand problem domains
more and more, we migrate more and more stuff from "the code" into
declarative formats that describe the data. RDF fans think that RDF is
the declarative "uber-format". We'll see. Maybe.
If they are wrong, I still expect dozens of declarative languages like
XML Query, XSLT etc. to mature into powerful tools for bootstrapping
understanding of a vocabulary. (consider for example an XSLT associated
with one industry standard purchase order vocabulary that translates it
into another PO vocabulary on demand -- easy to model in an
industry-neutral way with URIs and XML).
One reason I argue against the "standard web services" model because it
moves the very first bit of the problem from the domain of declarations
into the domain of code. I.e. to even get the data you need to write
code. That's a serious impediment to further exploration down the
declarative path. If XML Query turns out to be extremely wonderful and
powerful, this fork in the road should come into even greater focus.
Paul Prescod
|
