Joe Gregorio
I have updated the CommentAPI to incorporate feedback and added a table that summarizes the mappings from the other services to the CommentAPI. As always, feedback is encouraged.
That's where I was trying to head by asking what you return: I post a linkless fragment with my site URL in some other element, you return essentially the same fragment (possibly with my HTML stripped from the text because your comment rules prohibit it) but with the permalink inserted in link.
Stripping HTML reminds me that it would be nice to have some way of saying that you want a preview, that you are only POSTing to find out what's going to be done to your text.
Posted by Phil Ringnalda on 2003-03-19
Hmmm, that's an interesting idea, returning the altered RSS 'item' from the POST. It would also be real easy to implement.
Posted by Joe on 2003-03-19
What would happen if the app didn't support permalinked comments? would the returned URL simply be that of the corresonding post perhaps?
Still wondering what is happening with regards to namespaces withing the item fragment. Will the spec demand(?) that the appropriate namespace definitions are included in the item element?
Joe, thanks for the summary table, makes everything a lot easier to understand somehow :-) It's good to see that the major (current) uses all seem to fit quite nicely within standard RSS 2.0 too.
Posted by Adrian on 2003-03-19
Adrian,
If there weren't perma-links then the 'link' tag wouldn't be updated. More generally, any of the elements could be updated, for example the HTML could be stripped, elements and attributes in unknown namespaces removed, etc.
I'm thinking that maybe the best way to handle this is the Location: header. That is, do not return the altered 'item' from the POST operation, but instead return it's location in the Location: header. Thus if you are interested in it you could do a GET on that URI to retreive the 'item'. This makes the XML available for the people that want it but saves traffic in the majority of cases where you will only want to know that the comment was successfully accepted.
As far as namespaces, yes, all the namespaces _used_ in a document will have to be declared in that document.
Posted by Joe on 2003-03-20
Maybe I missed it somewhere, but what exactly should be returned in response to a POST if the comment does not generate a permalink? For Jot, posting a comment (through the HTML form) will redirect you (via 303 See Other) to the entry now containing the comment. In this case, however, should I just return a 200 and a copy of the RSS item?
Also, since I am not storing RSS and not all possible elements will be significant, should I still return those non-significant elements in the returned RSS item or should the item contain only the elements that were significant to Jot?
Posted by Seairth on 2003-03-20
*argh* sorry about the prior link. Appearently, I typed it in wrong.
Posted by Seairth on 2003-03-20
Joe,
Thanks, very helpful. I hadn't figured that it was acceptable to only take what the app wants from the incoming 'item'.
I'm not sure how much control ASP gives of the location: header for returning the URI of the 'item'. Will have to do some research on that one :-)
In ASP the XMLHTTP component just returns whatever is response.write written from the receiving ASP page. Whether that appears as/in (?) Location: header I don't have a clue.
Can the wfw:comment be used either within any TrackBack RDF or standalone on the HTML page as well as within the RSS feed? The tag ain't going to be much use in BlogWorks and stacking a whole pile of them up in the tag may not be such a good idea if most apps will just be looking for a single tag.
Posted by Adrian on 2003-03-20
Seairth,
I'd assumed that what was returned was the item with modifications made that would reflect how the app was using the information sent.
Joe,
Thinking about Phil's comment about preview and also thinking about how to differentiate the 'items' that come into the system would it be either possible or desirable to add two elements to the wfw namespace:
<wfw:preview> which would contain a boolean true if a preview was wanted by the calling app. The return would be the same as the standard return - modified 'item' but the nothing would be saved by the receiving app.
Secondly
<wfw:type> (or some such...) which would contain information about the type of item being sent - Comment, TrackBack, Post-It etc. This would enable systems that don't support certain types of 'incoming' to weed them out quickly. The list of approved names would expand as more methods of sending comments around increases.
I honestly don't know if that is where you want the spec to head so I make the suggestion hesitantly and being quite willing for the answer to be 'no'.
Posted by Adrian on 2003-03-20
Adrian,
I don't know if I want to consider those additions just yet. I would rather opt for a simpler specification up front and only add features later after seeing how this stuff operates in the wild.
Can you write up how you think the wfw:comment tag could be incorporated in the TrackBack RDF?
Seairth,
Just returning any HTTP success code should be acceptable. I.e. any of the 2xx or 3xx codes, if they are used appropriately.
Posted by Joe on 2003-03-20
If I was going to use the wfw:comment in RDF I'd probably do:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
xmlns:wfw="http://wellformedweb/CommentAPI/">
<rdf:Description
rdf:about="http://www.mysite.com/200303archive001.asp#1047583263001"
dc:identifer="http://www.mysite.com/200303archive001.asp#1047583263001"
dc:title="Test"
trackback:ping="http://www.mysite.com/trackback.asp?id=1047583263001"
wfw:comment="http://www.mysite.com/commentapi.asp?id=1047583263001" />
</rdf:RDF>
(All URLs are fictional but of the style produced by BlogWorks)
Although, to be honest I'd be tempted to just add it above each post as it's own element as used in the RSS feed of the site and forget the RDF.
On another track... At the moment pingbacks, trackbacks etc. etc. send back their own particular "success" messages. Is the idea of the CommentAPI to have a standard response to any of these different types of calls? So, trackback, pingback all return exactly the same thing - the modified item that shows how the received information is going to be, or is being, used.
I presume that eventually one won't want to distinguish between types of 'item' received, hence no need of a <wfw:type> element.
What happens then with some of the stuff that Ben Hammersley writes about at http://www.benhammersley.com/archives/003862.html such as BackTrack that presumably comes in in a similar fashion to TrackBack but needs a different kind of response from the modified item? Would the receiving app just have to recognize by any extra namespaced elements in the 'item' that this is a BackTrack rather than a TrackBack?
Posted by Adrian on 2003-03-21
What if the site requires some sort of authentication prior to accepting the fragment? (site owner may require registration prior to posting)
would it be an idea to add a <auth usr="whatever" pwd="whatever"> to the post fragment?
Posted by Jay on 2005-10-13
Posted by Joe on 2003-03-19