It’s just data

Orthogonal Extensibility

Daniel Berlinger: Sam's certainly consistent. Why the envelope Sam? No need to reiterate what it's used for in SOAP, but what's the benefit in this context? Why not just post the RSS and namespace the extensions? (as you suggest...) Does it improve interop when turning one standard into another? (just asking, no agenda)

Thank you. I've tried to be consistent.  Advocating a single, uniform, consise, and extensible data format as opposed to unique formats for each intended purporse.  Alternatives which generally are simultaneously more verbose and yet somehow manage to contain less information.  Alternatives which are considerably less extensible, if they are extensible at all.

Now in addition to the various uses I had collected before, I can add BlogPing.  I say collected, as I didn't invent most of these.  I have simply been collecting them in a manufactured serendipity sort of way.

Now to answer your question: the reason for headers is for orthogonal extensibility.  What does that mean?  Look at RESTLog.  Whatever I place inside the item is saved permanenty.  Suppose I simply want to pass an option to the RESTLog application itself?  Similar question for validation, for archiving, for pinging, etc.

No, I won't give you a specific example today.  I am merely recording observations, and encouraging people to leave room for potential future needs.  When they arise, I plan to still be here.  I am a very patient evangelist.


Sam responds to my query from the other day....

Excerpt from Archipelago at

One must always consider the opposite: when content becomes extensible in any direction, the distinction between "header" and "body" becomes blurred -- a historical optimization or vestigial meme.

Suppose I simply want to pass an option to the RESTLog application itself?  Similar question for validation, for archiving, for pinging, etc.

Suppose the datum one is sending should be handed off to a third party, should RESTLog know which headers to pass on, or now save the whole uber-item, header and all?

Posted by Ken MacLeod at

Wrapping the SOAP Envelope around a RSS Item would serve the same purpose as wrapping an HTTP payload into a multipart mime package along with the HTTP headers.  Some data (the payload) needs to go to the application for processing, some day (the headers) need to go to the infrastructure for processing.  Same thing here only view the RESTlog implementation as the infrastructure. Simple.

Posted by James Snell at

Ken - half of me strongly agrees with you and half of me is resistant.

Taking your position to the logical extreme results in a rather provocative question: why do we need HTTP headers?  ;-)

From a SOAP processing model perspective, everything is logically a header, but at least one element must be targeted for the default actor and must be considered mustUnderstand.  This series of constraints is enforced lexically by requiring a SOAP body.

What all this really boils down to for me is: how much valuable metadata can we get out of people who are otherwise unwilling or unable to produce it?

Posted by Sam Ruby at

Posting from RSS Bandit and XHTML in RSS

At the cost of optionally supporting an SOAP envelope and responding in kind, I get better and easier integration with tools and languages like Radio and  C#.  If two elements and future extensibility is too heavyweight for you, then no... [more]

Trackback from Sam Ruby

at

MustUnderstand = 'true'

Of course I should point out that a number of other toolkits fail the test, and that PocketSOAP doesn't do anything specific if it receives a response with an mU='1', however 4s4c does the right thing. I haven't seen discussed the expected behavior...

Excerpt from Glen Daniels at

Thanks  for this post, I am a big fan  of this website  would like to  go on  updated. Auto Glass Repair

Posted by Auto Glass Repair at

Add your comment