Don’t get me wrong, I love Google’s Social Graph API, it’s a great way to speed up the discovery of XFN data by using Google’s cache. What does not make sense to me, however, is their ‘NodeMapper’ concept that is built in to the API. It maps multiple URLs from a site on to, not a single URL, but a SGAPI-only URI scheme. It maps using URL patterns that are known about the site, so it doesn’t even work on the web in general. When it does work, what is it useful for? URL consolidation. The problem is, that the only thing you can do with a nodemapped URI is (1) use it as a unique key or (2) turn it back into a URL to get data.
I don’t get it guys. How is this better? Is there even a reason to consolidate things like FOAF files backwards to the main page, since most people will enter the main page itself as input anyway? Even if it was useful, shouldn’t it actually map to the main page and not to some proprietary URI scheme?
Thoughts? Anyone see a use for this that I’m missing? Or is this misfeature just adding a layer of data that someone might use and that we’ll have to hack around again later?
If you combine S5 with XOXO you get a format you can use to build simple slideshows for the internet and that makes sense to microformats parsers. S5 is a simple slideshow system with many features that can pull the data for slides right out of an XOXO block. To use S5 you will have to download the JavaScript and CSS files from the homepage and then build a page with slide content that links in these files. While there is a quite adequate S5-with-XOXO reference, the format will be summarised here for completeness.
Notes
S5 documents must be DOCTYPE XHTML 1.0 Strict, and there are certain <meta> tags that are required. See the specification for more details.
Meta Data
Meta data in S5 is encapsulated in a set of <meta> tags. This means that the data will not be available to XOXO-only processors. The page <title> must be the title of the presentation and the <meta name=”version” content=”S5 1.1″ /> element is also required, along with the tags to include the JavaScript and basic CSS.
There is also a controls/header/footer section that must be present first in the <body> tag before the XOXO data. The code for this section follows:
<div class=”layout”>
<div id=”controls”><!– DO NOT EDIT –></div>
<div id=”currentSlide”><!– DO NOT EDIT –></div>
<div id=”header”>
SLIDESHOW HEADER
</div>
<div id=”footer”>
SLIDESHOW FOOTER
</div>
Where SLIDESHOW HEADER and SLIDESHOW FOOTER are the contents for the header and footer of the slideshow, respectively.
Classes
In order for the S5 code to interface with your data properly the class ‘presentation’ must be present on the main <ol> or <ul> tag. The class ‘xoxo’ is also reccomended in accordance with the XOXO specification.
Nodes
Each root node in the XOXO tree for the slides must have the class ‘slide’. The direct contents of the node (along with any XHTML markup) are considered to be the text (/images etc.) of the slide. If the first element in the node is an <h1> element the contents of that tag are considred the title of the slide. Subnodes are rendered as points in the presentation. If the <ul> or <ol> root tag for the subpoints has the class ‘incremental’ the points will be introduced one at a time. Additionally a <div> element of class ‘handout’ will not be rendered on-screen but only when the presentation is printed.
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.
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:
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.