Use app:accept, screw the Atom Categories
Comments Off 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
2 Comments 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:
<body about=”http://example.com/mydoc#section”>
<div id=”popup”>
The document was written by <span rel=”dc:author”>Tim</span>
</div>
<a onClick=”…”>Show PopUp</a>
</body>
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 <http://example.com/mydoc#section> dc:author ‘Tim’. Instead, I get <#popup> dc:author ‘Tim’.
FeedMesh Python Solution
Comments Off 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)