It’s just data

Weblogs Content API

Don Box: Tim Ewald, Joe Beda, ChrisAn and I are trying to get the new format for exchanging items working.  Here's a preview of what it looks like now

This format has a number of interesting twists.  First, it is document literal XML which Anonymous [presumably Gary Burd] doesn't particularly feel is vi compatible.  I'd bet that Don's example was entered in Emacs.  Note that the cited xhtml namespace incorrectly points to the same namespace as the blog content.

Like prior iterations from Don, the content is included literally, with no need for encoding.  This brings up two questions: if literal XML encoding is acceptable for the body, why is it all of a sudden unacceptable for headers?  And how should multi-line headers, like the short description (sometimes referred to excerpts) be encoded?

What is also interesting about this example is that it separates the metadata from the content.  While this surprised me, it does makes sense from a SOAP processing model perspective: the one element in the body is intended for the ultimate destination (in SOAP parlance, this is the default actor) and must be understood, the others may be handled by intermediaries and/or disregarded.

I'm not sure what the right split between data and metadata is in this instance.  The split that Don, et. al. proposes does have the disadvantage of precluding the ability to the functional equivalent of pingbacks.


The only thing I'm interested in is which blog posting format you are going to support for comments.

Your blog is the only one I've seen which supports comments that I tend to regularly post to so whatever you support is what's going to end up in RSS Bandit.

Of course, thinking about it I'd love that whatever format ended up being accepted in the blogging world would be flexible enough to support authentication. Once that happens I might end up pressuring Rusty to support it on K5. :)

PS: You need to teach your splell checker that blog is a word.

Posted by Dare Obasanjo at

Sam,

I can't help but smile as I read your analysis - it's as if you were in the room when we were editing the schema!

All of that said, I don't think we're quite at the "proposal" stage - rather, we're simply noodling with some ideas and trying to be transparent about it.

DB

Posted by Don Box at

Hmmm... reinventing the wheel is, in many occasions, a great approach, but I think this wheel is a step backwards.  I much prefer the rss-in-soap approach over the lets-in-invent-yet-another-namespace-that-contains-the-same-information approach.

Posted by James Snell at

James,
I can't help but agree with you. Reusing an already existing technology that seems to overlap 100% and is already widely used seems to make sense.

Posted by Dare Obasanjo at

Why thank you Dare :-)

Posted by James Snell at

In the words of Don Box

  "Read Less Specs, Write More Apps"

Given the choice between reusing an existing technology (i.e. just code) and creating a brand new one (i.e.reading yet another spec) I definitely would prefer the former. It seems Don doesn't want us to follow his advice. :)

Posted by Dare Obasanjo at

I'm in complete agreement with James and Dare. This doesn't make a lot of sense to me. Its a step backward and it would be yet another spec. Which is why I lean toward advancing TrackBack rather then creating a separate Comments API.

Perhaps discussing how WSIL could be adapted to work more closely with RSS and other RESTful web services would be more useful. :)

Posted by Timothy Appnel at

Sam,
  Anchors have been added to the spec.

Posted by joe at

A New Spec that extensively leverages existing broadly adopted specs is goodness.  A New Spec that extensively reinvents existing broadly adopted specs without good reason is not goodness.  The problem with extending the existing Trackback is that it doesn't leverage existing specs and simply extending Trackback doesn't allow for very clean convergence (trackback + comments + pingback + REST + etc etc)... which is what we need to take blog function up a few levels.  Sure, it's widely adopted, but so is COM.

Posted by James Snell at

James: I suppose that we'll just have to agree to disagree and see how it all plays out.

Posted by Timothy Appnel at

Eventually we'll see convergence one way or the other.  The right solution will be whichever one the most people choose to implement.

For the record, none of the ideas I've seen floated so far are wrong.  What I see are degrees of desirability.  And for me, reusing existing specs is most desirable even if we need to invent new specs to allow us to reuse those specs.  Make sense?

Posted by James Snell at

Prior Art

Don's non-proposal garnered considerable criticism for not providing the appropriate amount of respect for prior art.  The following modest change to the header should address this: <soap:Header xmlns="http://purl.org/dc/elements/1.1/"> ...

Pingback from Sam Ruby: Prior Art

at

Dominoes

Dare Obasanjo: Your blog is the only one I've seen which supports comments that I tend to regularly post to so whatever you support is what's going to end up in RSS Bandit. What Joe Gregorio has defined will undoubtedly get supported in Aggie and ...

Pingback from Sam Ruby: Dominoes

at

Addendum dictionary

Due to persistant prodding by Dare, I've created an addendum dictionary.  Leave comments here if there are particularly troublesome words that you would like ...

Pingback from Sam Ruby: Addendum dictionary

at

Add your comment