Article:		Google's Gaffe
Subject:		XForms vs. REST?
Date:		2002-04-28 13:37:44
From:		Paul Prescod
Response to: XForms vs. REST?
"Having created several apps based on HTTP URI requests and primarily XML responses (with some other MIME types thrown in for certain requests, of course), I feel torn here. XML provides a much more elegant means of structuring sophisticated input data on the client and parsing it on the server than simple HTTP request parameters. Yet you need a simple HTTP request parameter access to directly use the given resource in countless use cases (bookmarks, XInclude, XSLT document(), AppletContext.showDocument(), etc, etc). It seems that you end up wanting (if not needing) both!" Yes, it is not always trivial to express what you want in a URI rather than in XML. But you really shouldn't need to parse the URI strings "by hand". Your programming language or framework should have tools for doing this, just as it has XML parsing tools. "In case the author is reading this, I believe XForms deserves further examination along these lines as to how it addresses these issues in terms of interoperability with both simple HTTP request parameter I/O and XML I/O -- or did I miss this article?" XForms is an excellent way to get a web UI to an XML-consuming web service. Note that I'm not against XML-consuming services: I just feel that the proper place for XML is as a representation for the data objects being manipulated and not as a marshalling format for parameters to a method call. Paul Prescod

Previous Message

Up

Next Message

• XForms vs. REST?
  2002-04-29 03:13:24 jim fuller
  
  'Note that I'm not against XML-consuming services: I just feel that the proper place for XML is as a representation for the data objects being manipulated and not as a marshalling format for parameters to a method call.'

  
  this smells a little bit,

  
  marshalling is the process of getting some possibly disparate bits of data--> put em in a buffer of some type--> organise/format as per the requirements of the reciever or programmatic interface. simple definition....

  
  this is a well known pattern when working between language x and language y....in actual practice marshalling has proven to be inordinately difficult, as the implementation becomes rather specific to lang x and lang y, *because* there has been no agreed upon meta data format between the two; when there is an agreed upon meta data format this becomes easy; look at WDDX for example.

  
  now that xml is and will be ubiqitous, internally and externally within lang x and lang y or remote procedure blah blah..... the idea of marshalling may change....( why fax when one can irc ? ).

  
  the key issue, with most xml technologies;

  
  a) does xml define a process with some sort of xml based language

  
  or

  
  b) is xml the substrate or format of this process

  
  most efforts tend to mix the 2...

  
  a few examples;

  
  - in the EXSLT effort, we decided to generate standard *definitions* of functions, instead of binding the actual implementation with the definition. How many times has a simple function like string tokenize function been implemented in how many different languages ?

  
  - in the XForms effort, there seems to be a lot of implementation specific details, along with generic form definition; mixing of the 2 strategies creates subtle situations, that are confusing for tool developers and authors, i would always like to see clear seperation between definition and implementation ( once again my mouth waters at the UML code generation aspects... )

  
  - if one views SOAP as an IDL or definition format, then who cares what actually goes over the wire ? you are ( at its simplest ) one transformation away from whatever format that will become. ok, this is simplistic, but what to me is more important is to define a language which defines the process, instead of becoming both definition and implementation.

  
  - WSDL is currently being adopted because it kind represents the URI in the REST equation for developers and web services users to *use* the service; this seems to be the useful cog in the whole system at present; especially with the auto code generation within the various languages; though i for one can foresee some issues down the line if we continue to use WSDL.

  
  In almost every situation, i would opt for creating a *definition* in xml format, to give a coherant meta data skeleton which can then be fleshed out with any implementation ( using xml or not ).

  
  - xml *is* the meta data format of choice

  
  - having meta data everywhere is useful for assisting in deploying and defining web services

  
  - the overall process should be defined by an xml language

  
  The main problem i see is that in a world of SOAP, developers will defined complicated mesaging patterns using the SOAP headers.... which is an example of modeling with implementation, why not use XML pipeline ( on services steriods )to semantically model the marshalling requirements etc.... then have a transformation into DCOM (hehe ) implementation code ?

  
  cheers, jim fuller