[FoRK] SOAP vs REST

[Stephen D. Williams]

silky wrote:
> On Sat, Apr 12, 2008 at 3:27 AM, Stephen Williams <sdw at lig.net> wrote:
>   
> ...
>>  DTD's are verboten as far as I'm concerned.  Dead.  Stupid.  Bad idea.
>>  xslt is interesting, but I would only use it in narrow circumstances.
>>     
>
> why only narrow? i am now trying to format/process an fxcop report. i
> went to their namespace and found the link is dead [ms retired
> gotdotnet] so now i am just going to make up an xslt sheet and
> transform it myself to html, because it's the fastest way over parsing
> it manually [i guess], but it's still annoying.
>   
XSLT seems great for what it covers, which is a lot.  It is not 
necessarily the only thing I would use for transforming data.  Does 
anyone, for instance, use it in application development just to 
transform data (memory to memory)?  Forgetting format of the data (which 
should be immaterial, as the API below illustrates) and the availability 
of a suitable library and language integration (fixable for most 
languages), would you rather write XSLT than Python/Java/JS/C++ to do 
the same things?  Sometimes yes, sometimes no probably, but not 
overwhelmingly yes I bet.
>> Namespaces are fine, but you typically only need one or two for an
>> application.  There isn't much to it, just name scoping.  Since URI's are
>> the W3C's answer to GUIDs, and they are better, you need some way of
>> avoiding long IDs everywhere when you want to uniquely specify identity and
>> typing.
>>     
>
> i personally have uri's as GUIDs, but that's just me maybe.
>   
What I was saying is that everyone is going to URI's as GUIDs.
>> And you don't need a schema.  In fact, I don't like schemas for a range of
>> application communication.  [Long discussion deferred.]
>>     
>
> pending that discussion i may agree with you.
>
>
> ...
>>  In fact, you can have a data format that doesn't need serialization or
>> parsing and can optionally encode data as portable binary scalars that uses
>> the same API.  That's esxml / esdom.
>>     
>
> hmm sdom + ajaxy ..... (sdomy)
>   
Oh, uh, yea.
>   
>>  sdw
>>     
>
>   

sdw