BadPopcorn » XML

Use app:accept, screw the Atom Categories

Ben — Thu, 26 Jul 2007 10:08:04 +0000

It’s been a while since I’ve revisited the Atom Publishing Protocol, so I just had to review (briefly) the latest APP Draft (17) since it’s probably going to be the one that becomes an RFC standard. I noticed something that I must have overlooked before: the app:accept element. Without even looking through the past drafts, I have a gut feeling that it’s been in the APP for quite some time; and I have the feeling that I had a misguided pursuit of using Atom Categories as service type descriptions.

On the surface, one may think that the app:accept is just for giving the mime-type of whatever resource one wants to create in an APP Collection: jpeg, gif, some xml. Let’s look at the “application/xml” mime-type. It describes many many XML documents that represent many resources. One may be a shopping cart order, or it may represent a classified ad. And this is why I may have overlooked the accept element before: a generic mime-type is generally too broad for describing the semantic meaning of the Resource represented using said mime-type.

But, one can aptly describe the what “Service” a server will provide as a side effect after one POSTs a new Resource to a collection (for creation) by using the Accept Extensions as described in the APP app:accept section– note that app:accept refers to Accept Header section (14.1) in RFC2616. Examples of such side effects are the creation of other Resources in other Collections by the server.

So, in the app:accept example in the new APP Draft (17), it is implicitly suggested to use the “type” extension to describe, semantically, what a Collection will accept and process server side. Example: `application/atom+xml;type=entry` for normal atom entries. In my services now, I can add some extra domain specific restrictions on POSTed Resources with an app:accept like `application/xml;type=”http://example.com/online_orders/flower_basket_order.dtd”`. But don’t use DTDs, it’s just an example. Or try `application/xml;type=com.example.some.resource.type`. Note that one has to be careful about quoting (“) values. In the first case, I had the separators (as defined in RFC26162) slash (/) and colon (:) in my URI; where as the second case had no separators. And also note that what one (as a good APP citizen) POSTs Resources, not RPC requests.

So what are Categories good for? I haven’t had much time to reflect on that, so maybe it’s good to use Categories if I had a generic “http://example.com/online_order.dtd” resource type that is used for all types of orders: flower baskets, bicycles, or electronics. Have a Collection for bike orders whose category may be “http://example.com/bikes”, and another for Flowers…

And all this makes sense to me because we want to be Resource Oriented, and mime-types are the preferred route in describing Resources. I say this is good stuff.

RDFa Complexities

Ben — Sun, 18 Mar 2007 09:12:51 +0000

So I briefly read over the new draft of the RDFa Primer. It’s good overall, but Section 5 introduces unnecessary interpretation complexities.

I say BLEAH to the Section 5. I want “Keep It Simple, Stupid.” parsing. The nested layers make it harder for the parser to parse; it makes it harder for the lay person to understand RDFa (and to adopt, and to use).

I also REALLY don’t like the idea of intermixing the id and about attributes for use in defining the subjects & objects. Although the primer makes a case for it, I counter with this example:

Show PopUp

The ‘popup’ id is overloaded. It’s the identifier for which the Javascript code looks up, and it’s also become the subject of the dc:author statement. The above fragment is also non-intuitive. I would expect dc:author ‘Tim’. Instead, I get <#popup> dc:author ‘Tim’.

FeedMesh Python Solution

Ben — Fri, 11 Nov 2005 19:11:47 +0000

Ralph Meijer’s blog has a nice entry about connecting to the FeedMesh network, even with sample code.

This solution was exactly what I was looking for. The Twisted Framework is used for handling both the network connection and the XML streaming (Xish package).

However, I ran into a little problem when testing the code out. I found was that the XmlStreamFactory failed to instantiate. It required another parameter in its constructor. WTF?

Simple reason. Ralph has been making changes to remove all the Jabber specific stuff out of Xish. That parameter was for Jabber and Ralph’s changes haven’t made it out into a new release.

So, for those that already have Xish 0.1.0 installed, here are the following code changes:

auth = xmlstream.Authenticator('')
f = xmlstream.XmlStreamFactory(auth)

Original Sample Code:

from twisted.xish import xmlstream
from twisted.internet import reactor

def onPing(element):
    print 'Ping for %s' % (element['rss'])

def connected(xs):
    print 'Connected!'
    xs.addObserver('/weblog', onPing)

f = xmlstream.XmlStreamFactory()
f.addBootstrap(xmlstream.STREAM_START_EVENT, connected)

reactor.connectTCP('sandbox.pubsub.com', 9999, f)
reactor.run()

[Edited: Changed the code tag to a pre tag (Of the code samples) because those sections weren't rendering nicely.]