[
Lists Home |
Date Index |
Thread Index
]
Joshua Allen wrote:
>
> > The "SOAP brings interop for free" argument is simply a straw man.
> > Especially when it necessarily prevents interop with a whole
> > class of tools (XSLT processors for one).
>
> BTW, this is absolutely and completely wrong. SOAP messages are XML,
> and therefore are able to be transformed with XSLT just like any other
> XML. Many people have done this (and yes, I have too).
In fact in my upcoming article I will in fact transform SOAP with XSLT.
But the point is that SOAP result sets cannot be *addressed* by the only
standarized I/O facility available in XSLT (and XPointer, and XPath and
XInclude and RDF and ...) the URI-dereference (spelled in XSLT with the
"document") function. To even *get* SOAP data to an XSLT processor you
must use some other language that implements the SOAP API.
This is also my response to your pointer that Google is used with RDF
somewhere. Yes, its all just bits and you can always write one line or
one thousand lines of code to munge one data source into another. I
suspect the app you sent me is screen scraping, not using the new API,
but it doesn't matter. Either way, it's fundamentally unscalable. One
shouldn't need to write glue code to relate information resources.
Paul Prescod
|
