Singpolyma

Archive for January, 2006

Archive for January, 2006

Blogger Comment Permalinks

Posted on

Johan of Ecmanaut has pointed out on a couple occasions that Blogger’s ‘default’ comment permalink URL was POSTURL#cCOMMENTID. I had never found much proof of this claim, except for some default code in the blogger templates — but some of them (like the one mine is based off of) actually have the anchor that works set to the above, and the links themselves set to #COMMENID with no ‘c’… confusing that.

In some recent work I did on the XOXO Blog and in the creation of the Commentosphere Userscript I found out something very disturbing — this discrepancy extends beyond the template codes! Johan’s claim stems from the fact that the anchors on comment pages (those ugly things I partly avoid by my inline comments form) use the #cCOMMENTID format, and hence his commentblogging script (and my commentosphere script) both pull in this format when passing data to del.icio.us or commentosphere, respectively.

There is, however, a Blogger template tag (<$BlogCommentPermalinkURL$>) that is meant to output the entire permalink of a comment (including posturl), something I’ve been looking for for awhile to alleiviate the need for the ugly JavaScript hackery I have in my blog template to facilitate the same. This template tag, however, outputs using the #COMENTID format! If this isn’t confusing I don’t know what is — which one is standard, Blogger?

For now, I would reccomend using both. How? Change your comment anchor to read something like <a id=”c<$BlogCommentNumber$>” name=”<$BlogCommentNumber$>”> </a>.

Commentosphere – Importer and Userscript

Posted on

After much trouble and headaches with the speed of the Ning backend, the Commentosphere Delicious Importer is working! Numerous recent updates and optimizations to Ning seem to have greatly increased the speed of the backend, which was what was dragging down the original. I created a test app clone of Commentosphere and successfully imported 70 comments from some test data Johan sent me awhile back to make sure that it really was working this time.

There is also now a Greasemonkey userscript for posting to Commentosphere! Based off of Johan’s commentblogging userscript, it adds a link to all comment post pages on Blogger blogs that links to the Add a Comment form on Commentosphere, already filled in with the necessary information for your new comment. One thing I would like to add to the script is the ability to select parent comments from the comment page, instead of having to get that data manually if you want it. It is still recommended to run with both the userscript and the bookmarklet — for posting comments from non-Blogger blogs.

XOXO Blogroll Format

Posted on

The purpose of this format is to define a standard way of marking up blogrolls, subscription lists, etc. This is a derivation of, and not an actual part of, the XOXO specification. Much of the content of this format is taken directly from the specification itself.

Terms

  • A reccomended field is one that should be included in output meant to comply with this format
  • An optional field is one that does not need to be included
  • A-fields are fields stored within the markup of the primary <a> tag in an XOXO element
  • Alternate-A fields are one stored with second, third, etc <a> tags
  • DL-fields are ones stored within the optional <dl> list

Note that no fields will be marked as ‘required’. This is because, in full compliance with the XOXO specification, the only required field is ‘TEXT’ (the direct contents of the <li> or <a> tag).

Classes
In compliance with the XOXO specification, no classes are required on the main <ul> or <ol> tag. Two classes, however, are reccomended in order to identify XOXO sections complying with this format. The ‘xoxo’ class (as defined by the XOXO specification) is highly reccomended, as well as the additional class ‘blogroll’ (which is also part of the XOXO specification, as much of this format has been directly adapted from there).

Meta Data
The first element will be considered by this format to be metadata for the entire section if there is no HREF or ‘contents’ and there are more fields than TEXT. The following fields are defined for metadata:

  • title — XOXO section title
  • ownerName — Name of list owner
  • dateCreated — Generation date of data

Nodes
All nodes in this format are considered to be one of two things — structural elements or link elements. Structural elements form the categories/hierarchy and link elements are the actual content. For extensibility reasons, link nodes are defined as all nodes containing the HREF or the ‘contents’ field. Structural elements are all other nodes.

The TEXT Field

  • The TEXT field on link elements stores the title of the resource
  • The TEXT field on structural elements stores the name of the section

A-Fields (link elements only)
The primary A Field is considered to be an ‘alternate’ URL (ie to a feed of some kind) if it has rel=alternate, rel=rss, or rel=atom. Otherwise it is considered to be the URL to the resource itself (ie an XHTML page). The alternate-a fields follow the same logic — with the exception that at the point where the URL to the resource itself is discovered, all subsequent fields are considered to be ‘alternate’ URLs. Note: A and Alternate-A fields with a ‘javascript:’ HREF attribute are to be ignored.

  • HREF (reccomended) — URL to resource or alternate resource
  • TITLE (optional) — Extended description of resource
  • REL (optional) — If link to feed this may be ‘alternate’, ‘rss’ or ‘atom’, depending on the type of feed

Alternate-A Fields (optional, link elements only)

  • HREF — URL to resource or alternate resource

DL-Fields (link elements only)

  • contents (optional) — for extendability purposes only, stores the contents of a resource that is not URL-based
  • tags (optional) — stores tags for the resource, in one of two formats. It can store a space-separated list of the tags, or a list (<ul> or <ol>) of relTag data. The interpretation of this relTag data should be leniant and ignore the HREF value completely. Anything in the list that does not have rel=tag is ignored.

XOXO Data Tools

Posted on

So you’ve got some XOXO content or are using an XOXO Blog Format template… what can you do with it? This post lists tools that work with XOXO content. Please notify me if you know of any that aren’t listed here.

Conversion

  • Outline Convert — auto-detects input format from URL or direct input and then converts to a specified output format (XOXO and OPML currently supported, RSS/ATOM supported on input only).

Syndication

  • Blogger Recent Comments — pulls data from XOXO Blog Format templates (or hAtom templates with the comments extension) and creates comments feeds in RSS2.0, JavaScript, and JSON. It assumes nanoseconds in the timestamp.
  • hAtom2RSS — converts XOXO Blog Format or hAtom data to RSS 2.0. Supports all the XOXO Blog Format extensions when in hAtom mode.
  • feed2hAtom — converts an RSS or ATOM feed to XOXO Blog Format-compatible hAtom

Misc

  • XOXO Validator — checks a URL or inputted code snippet for XML well-formedness and the precense of valid XOXO sections.
Tags:

XOXO Blog Format

Posted on

The purpose of this format is to define a standard way of marking up blogs with XOXO. This is a derivation of, and not an actual part of, the XOXO specification. This format is actually a hybrid format between XOXO and hAtom.

Terms

  • A reccomended field is one that should be included in output meant to comply with this format
  • An optional field is one that does not need to be included
  • A-fields are fields stored within the markup of the primary <a> tag in an XOXO element
  • Alternate-A fields are one stored with second, third, etc <a> tags
  • DL-fields are ones stored within the optional <dl> list

Note that no fields will be marked as ‘required’. This is because, in full compliance with the XOXO specification, the only required field is ‘TEXT’ (the direct contents of the <li> or <a> tag).

Classes
This is a hybrid format between XOXO and hAtom and parsers are expected to be able to read either ‘half’ of the format. XOXO-only versions of this format should have the classes ‘xoxo’ and ‘posts’ on their root tag. hAtom-only (or hAtom with extensions) versions should use the hAtom ‘hfeed’ class. Data complying with both ‘halves’ of this format should have all three classes on the root. Neither hAtom nor XOXO actually requires any classes at all on the root, but if no data is found with any combination of the classes specified here parsers are to treat the entire document as hAtom. Then, if still no data is found, parsers should look for XOXO data that does not have the proper classes.

Meta Data
The first element will is considered by this format to be metadata for the entire section if rel=home. This part of the format is not found in hAtom and is only supported in XOXO-only or hybrid versions of this format. The following fields are defined for metadata:

  • TEXT — blog title
  • TITLE — blog description
  • HREF — URL to blog main page
  • CLASS — ID of blog
  • Alternate-a rel=alternate
    • TEXT — immaterial, just a label
    • HREF — URL to blog feed

Subnodes
Subnodes, as defined by this format, encapsulate the comments on a post. Comment encapsulation is not supported by hAtom but is considered by this format to be an extension thereof. hAtom-only documents may be extended to encapsulate comments by outputting an XOXO section with the same fields specified for subnodes in this format in each hentry where there are comments. This XOXO element must have the classes ‘xoxo’ and ‘comments’.

The TEXT Field

  • The TEXT field on elements stores the title of the post encapsulated by that section.
  • The TEXT field on subnodes is immaterial.

A-Fields
On elements:

  • HREF (reccomended) — this field stores the permalink URL to the post
  • TITLE (optional) — this field stores the timestamp of the post (seconds or nanoseconds since the epoch)
  • REL — should be set to ‘bookmark’, in keeping with hAtom
  • CLASS — should be set to ‘entry-title’, in keeping with hAtom (Note: if there are no A-fields, TEXT must be encapsulated in a tag and given the class ‘entry-title’ to maintain hAtom compatability)

On subnodes:

  • HREF (reccomended) — this field stores the permalink URL to the comment. If the field contents begin with ‘#’ the parser is expected to resolve it based on the post URL.
  • TITLE (optional) — this field stores the timestamp of the comment (seconds or nanoseconds since the epoch)

Alternate-A Fields
On elements:

  • When rel=comments (reccomended) this is not supported by hAtom is is considered by this format to be an extension thereof. To use this field in hAtom-only documents place a rel=comments link in the appropriate hentry elements.
    • TEXT — number of comments on post (if non-numeric, assumed unknown)
    • HREF — URL to comments on post
  • When rel=author (optional, required by hAtom)
    • TEXT — this field stores the name of the post author
    • HREF — URL to post author’s profile or home page

    To be compatible with hAtom, this link should be encapsulated in an ‘address’ tag with the classes ‘author’ and ‘vcard’. The link itself should have the classes ‘url’ and ‘fn’.

  • When rel=archive (optional) the ‘updated’-classed field is required by hAtom
    • TEXT — datetime-design-pattern datestamp for post
    • CLASS — should be set to ‘published’ and ‘updated’ for compatability with hAtom
    • HREF — URL to the archive the post is in
  • When rel=’alternate comments’ (optional) this is not supported by hAtom is is considered by this format to be an extension thereof. To use this field in hAtom-only documents place a rel=’alternate comments’ link in the appropriate hentry elements.
    • TEXT — immaterial, just a label
    • HREF — URL to feed for comments on post
  • When rel=external (optional) this is not supported by hAtom and is considered a mostly unnecessary piece of information. It is not supported as an extension and should only be used in XOXO-only or hybrid versions of this format.
    • TEXT — immaterial, just a label
    • HREF — URL to external link for post

On subnodes:

  • The first alternate-a tag is assumed to be data for the comment author (reccomended)
    • TEXT — author name / nickname
    • HREF — author URL

DL-Fields
On elements and subnodes:

  • body (reccomended, required by hAtom) — the post/comment body
    To maintain hAtom compatability the post body dd tag should be given the class ‘entry-content’

Subnodes only:

  • Author — Author name. Should only be set if the author has no URL and cannot be stored in the Alternate-A field. However, if there is an ‘a’ tag in the value of this field it should be parsed, the HREF used for author URL and the TEXT used for author name.