Re: Possible news item: XRX

I quite agree with you. But what I noticed is that recently it has been  
coming up more and more on Google alerts, and I thought it might be worth  
bringing attention to it.

Steven

On Wed, 27 Aug 2008 19:25:34 +0200, Mark Birbeck  
<mark.birbeck@webbackplane.com> wrote:

> Hi Steven,
>
> I think XRX is generally a good thing, but its origins are actually in
> an _approach_ that is more flexible than simply relying on XQuery.
>
> The main ideas behind XRX go back a few years. For example, nearly two
> years ago I gave a talk to XML UK and W3C UK and Ireland on "XForms,
> REST, XQuery...and skimming" [1]. The talk described the XRX
> architecture as being a set of decoupled and standard interfaces,
> which come together to create a framework that requires very little in
> the way of server-side maintenance.
>
> This theme of XRX (and the more general notion of 'skimming') as being
> an architecture that provides low maintenance applications as well as
> speedy development, is part of a tutorial called "skimming -- The
> lighter way to program" [2].
>
> This tutorial shows how to first set up eXist and then use it to
> manage some contacts, via an XForm. The tutorial specifically refers
> to a Ruby on Rails version of the same example in an attempt to show
> that 'XForms + eXist' is a lot easier to set up.
>
> But although I don't mind the name 'XRX' being used to describe this
> architecture, I prefer the term 'skimming' because it emphasises the
> _approach_ rather than the technology.
>
> For example, in my post "skimming at XML 2007 (and The Cloud's Silver
> Lining)" [3] I looked at how you can go further with the
> 'loosely-coupled' approach and make use of Google's GData as the data
> source (still using REST, of course). I also looked at Amazon's
> SimpleDB which opens up similar possibilities, by providing a database
> 'in the cloud'.
>
> In other words, whilst REST and XForms seem to be constants, there are
> many other ways to address the question of data format and querying.
> For example, SPARQL is in many situations a more appropriate choice
> than XQuery, and JSON fits some scenarios better than XML.
>
> As it happens, I think that XML databases like eXist and MarkLogic are
> already evolving to incorporate this, and certainly from our point of
> view, the really important thing is that XForms makes
> 'loosely-coupled' architectures much, much, easier to build and
> maintain.
>
> Regards,
>
> Mark
>
> [1]  
> <http://internet-apps.blogspot.com/2006/09/xforms-rest-xqueryand-skimming.html>
> [2] <http://formsplayer.com/node/457>
> [3]  
> <http://internet-apps.blogspot.com/2007/12/skimming-at-xml-2007-and-clouds-silver.html>
>
>
> On Wed, Aug 27, 2008 at 3:43 PM, Steven Pemberton
> <steven.pemberton@cwi.nl> wrote:
>>
>> XRX: Simple, Elegant, Disruptive
>>
>> A meme gathering momentum is "XRX" - XForms on the client, REST  
>> interfaces,
>> XQuery on the server.
>>
>> One posting was by Dan McCreary on xml.com
>> (http://www.oreillynet.com/xml/blog/2008/05/xrx_a_simple_elegant_disruptiv_1.html),
>> which contained the memorable quote
>>
>>        Traditional methods required approximately 40 inserts into  
>> separate
>> tables within a relational database.
>>        The use of XForms and eXist resulted in one line of XQuery code:
>>
>>                store(collection, file, data)
>>
>>        That was it. Simple. Elegant. I was hooked.
>>
>> Since then the meme has been popping up elsewhere. For instance, see
>>
>> XRX
>> http://en.wikibooks.org/wiki/XRX
>>
>> XRX: Performing Updates
>> http://news.oreilly.com/2008/07/xrx-performing-updates.html
>>
>> @@ Anyone want to add to the list?? @@
>>
>> Steven
>>
>>
>>
>
>
>

Received on Friday, 29 August 2008 08:34:49 UTC