Yes, I know, another post on a Ning app of mine. Wrinks is an app for the creation/management of webrings, blogrings, linkrolls, and blogrolls. Ring/roll creators have full power over what sites are members of their wrink and wrinks can be embedded in web pages using either JavaScript or PHP (depending on your hosting situation) as either webrings or blogrolls. The service aims at being a sort of ‘social blogrolling’ system. The first person to add a site to the system has control over that site’s metadata (title, description, feedurl, etc.).

Traffic data is stored for each Wrink and wrinks can be browsed by tag, sorted by traffic number. These lists of wrinks can be syndicated via either RSS 2.0 or JSON(P). Each wrink can also be retreived via JSON(P) for custom inclusion in webpages.

Wrink rolls can also be filtered by tag. Each site on a roll has tags, and if &tag= is passed to the wrink, only sites matching that tag (or tag intersection) are returned. This opens the way for the possibility of filtering blogrolls by tag.

You can convert your XOXO blogrolls to reading lists, in either XOXO or OPML format, for use in feedreaders. Reading lists can also be easily converted into XOXO blogrolls. The steps to do either are below:

Blogroll to Reading List

1. Go to the Outline Converter
2. Select the appropriate reading list format from the ‘Output Format’ dropdown box
3. Enter the classes that are on your blogrolls, space-separated (ie ‘xoxo blogroll’)
4. Check the ‘Simplify’ and ‘Ensure HTML and XML URLs’ checkboxes
5. Enter the URL to your blog
6. Click ‘Convert’

Reading List to Blogroll

1. Go to the Outline Converter
2. Select ‘XOXO’ from the ‘Output Format’ dropdown box
3. If converting from an XOXO reading list, enter the classes on the list data into the ‘classes’ box, otherwise enter ‘xoxo blogroll’
4. Check the ‘Simplify’ and ‘Ensure HTML and XML URLs’ checkboxes
5. Enter the URL to the reading list or cut-and-paste in the reading list data

Note that the Outline Converter outputs the application/xml header for either OPML or XOXO data. XOXO data will thus not render directly in your browser as XHTML, but it is still valid data.

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.