XML Editor - Download a Free Trial >
See What's New >
Buy Now >

[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Transformative Programming: Flow-based, functional,and mor

  • From: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
  • To: Peter Hunsberger <peter.hunsberger@gmail.com>
  • Date: Fri, 18 Oct 2013 19:31:36 +0000
RE: Transformative Programming: Flow-based
Play the video
Whoops!  Cut and paste error.
 
But perhaps it is a small indictment after all.
 
Cheers,
Peter

From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
Sent: October 18, 2013 15:28
To: Rushforth, Peter
Cc: Uche Ogbuji; Simon St.Laurent; xml-dev@lists.xml.org
Subject: Re: Transformative Programming: Flow-based, functional, and more

Hi Peter,

you left out " and you actually get JSON" when you quoted me, which lends a rather ironic twist to your statements that follow.  I know you didn't intend it that way, but now reads as a bit of a blanket condemnation of all things XML if one isn't paying attention...

Peter Hunsberger


On Fri, Oct 18, 2013 at 2:20 PM, Rushforth, Peter <Peter.Rushforth@nrcan-rncan.gc.ca> wrote:
> the fact that the parties do in fact have expectations as to the contents of the resources and the HTTP headers and MIME types shape those expectations.  If I claim to be delivering you XML the loose coupling is now a bug, not a feature.
 
Therein lies an essential point.  Merely delivering application/xml is not good enough, since (according to REST) the engine of application state is in the content, application state is now effectively stalled when it receives such a message.  The only useful thing one can do with application/xml is present syntax coloured elements attributes and angle brackets.  No application would request application/xml if it had/knew of a more specific option, in which the *semantics* of the markup had been documented, by a media type registration possibly. 
 
If I send application/json to you after you have negotiated for application/xml, I have broken the contract of the Web.  Shame on me. I'm ignoring the separation of resource identity from representation.    If I allow links (resource identifiers) to be marked up (assuming my clients know how to recognize a link I mark up) without also marking up representation metadata, I continue to ignore that separation.  That all works well when I completely understand the assumptions built in to the semantics of the format I'm processing (e.g. I know that an img@src should lead me to a png, jpg etc.  Likewise an a@href leads to another text/html representation).  But it doesn't work at all when I don't know what representation to request.  And in the case of the XML family of formats, there may certainly be more than one representation of the resource which could be described as application/xml.  How does the server choose?
 
The diversity of markup (where it exists at all) for accessing the Web from XML *impedes* its progress.
 
The loose coupling that is often touted as a feature of REST is that betwen client and server.  There remains strong, tight coupling between the client and the format, as well as strong coupling between the server and the format.  But because the format is (potentially, as in a media type registration) defined outside of the scope of the client organization and the server organization, the pain is slower to materialize. 
 
Should XML ever decide to incorporate hypermedia into application/xml, or some future iteration of it, it would enable formats based on it to benefit from that loose coupling.
 
Cheers,
Peter Rushforth

From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
Sent: October 18, 2013 14:24
To: Uche Ogbuji
Cc: Simon St.Laurent; xml-dev@lists.xml.org
Subject: Re: Transformative Programming: Flow-based, functional, and more

Uche,

I think we've got a little mixture of concerns going on here. I'd expect one can describe some form of (2D or more?) continuum from tuples to DCS/COBRA and if you did so, REST would be sitting far closer to the simple tuple origin than the other. However, REST is an architecture for data exchange/manipulation, tuples are a formal mathematical model. Even at the REST resource level I'd be hard pressed to apply the tuple description to the resources unless you want to regard them as purely opaque blobs? I actually like that view of the REST resources (since, as you point out it allows for loose coupling), but it  denies the reality that the utility of REST comes from the fact that the parties do in fact have expectations as to the contents of the resources and the HTTP headers and MIME types shape those expectations.  If I claim to be delivering you XML and you actually get JSON the loose coupling is now a bug, not a feature.  (Though SImon seems to imply I should just go ahead and figure out what parser to use and cope with it anyway... ;-)

Peter Hunsberger


On Fri, Oct 18, 2013 at 12:35 PM, Uche Ogbuji <uche@ogbuji.net> wrote:
On Fri, Oct 18, 2013 at 8:01 AM, Peter Hunsberger <peter.hunsberger@gmail.com> wrote:
The Verb/Resource model of REST is not a simple tuple pair, unless you referring to PUT / GET parameterization which is probably a perfect example of why such interfaces are so error prone.  The rest (um, no pun intended) of HTTP carries with it headers and Mime types pointing to varying levels of formal specification as to the resource contents with varying success.

I don't understand why you think that the fact that e.g. HTTP has headers or uses a controlled vocabulary in the form of MIME prevents it from being a simple tuple-space-style architecture. Having worked with tuple-space-style architectures before the Web (e.g. Linda derivatives) I don't see much great distinction. I *do* see a huge distinction, on the other hand from DCE/CORBA-style tightly-bound cross-application architectures, again having done a lot of work on those as well.

I believe that REST is precisely in line with the idea of loose coupling between apps. However, as has been pointed out, scalability becomes the tricky problem even when you've architected things the right way.


--
Uche Ogbuji                                       http://uche.ogbuji.net
Founding Partner, Zepheira                  http://zepheira.com
Author, Ndewo, Colorado                     http://uche.ogbuji.net/ndewo/
Founding editor, Kin Poetry Journal      http://wearekin.org
Editor & Contributor, TNB     http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net    http://www.linkedin.com/in/ucheogbuji    http://twitter.com/uogbuji


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

XML Editor - Download a 15 Day Free Trial Now >
See What's New in Stylus Studio >
Buy Stylus Studio - XML Editor - Now >
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.