[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Transformative Programming: Flow-based, functional,and mor
> 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
[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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|