xoxo-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(moving stuff about OPML to xoxo-opml-issues)
 
(9 intermediate revisions by 9 users not shown)
Line 51: Line 51:
CSS styling could make this as pretty or not as desired.
CSS styling could make this as pretty or not as desired.


See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://blogxoxo.blogspot.com/2006/01/xoxo-blogroll-format.html XOXO Blogroll Format]
See also [[blog-info-examples]], [[blog-info-formats]], [[blog-info-brainstorming]], [http://singpolyma.net/2006/01/xoxo-blogroll-format/ XOXO Blogroll Format]


=== Wishlists ===
=== Wishlists ===
Line 168: Line 168:
== OPML/XOXO conversion ==
== OPML/XOXO conversion ==


It would be useful if XOXO could be used in a consistent way as an XHTML representation of data in the OPML format. On that basis, I'm going to collect a list of all the uses of OPML and try to map them in a consistent way to XOXO, and then construct an XSLT stylesheet to convert them. --[[User:TomMorris|TomMorris]] 10:02, 10 Aug 2007 (PDT)
This has been moved to [[xoxo-opml-issues]]. [[User:TomMorris|TomMorris]] 18:44, 3 December 2009 (UTC)
 
=== Principles for conversion ===
* OPML specifies limitations in a loose way, using the '''type''' attribute. There is some formal canonicalisation (in the [http://opml.org/spec 1.0 spec] and the [http://opml.org/spec2 draft 2.0 spec]) of what individual type attributes do. Type attribute values extend the standard attribute set of the outline node. So, for instance, the "rss" type value tells the processor to look for feed-specific values.
 
=== MIME type ===
OPML is usually served with a large variety of MIME types including:
* text/html
* application/xml
* text/xml
* text/x-opml
 
There have been suggestions as to whether or not to start serving OPML as:
* application/xml+opml
 
One should not infer that something is or is not OPML based on the MIME type, because that's not reliable. But all OPML-to-XOXO tools ought to point to OPML files (includes, etc.) in a consistent way. That way, JavaScript could be laid over the top of XOXO outlines to allow them to include OPML outlines or link to them in a way that would proxy them back in to XOXO (etc.).
 
=== Text attribute ===
There is some confusion over the difference between the '''text''' and '''title''' attributes. Both are reasonably well-defined by the OPML specification, and serve different purposes. Some implementations of OPML break from the specification in providing a title attribute but not a text attribute. If a text attribute is present but not a title attribute, one should infer that the text attribute is equal to the title attribute. One '''should not''' infer that the title attribute is equivalent to the text attribute (see [http://opml.org/spec2 OPML 2.0 Spec]).
 
The text attribute can and does often contain escaped HTML markup (which is really a bad practice, and has led to a lot of criticism of OPML). This is standard behavior from the OPML Editor. An OPML-to-XOXO parser should ideally take data from the text attribute and put it into a XOXO outline in a standard way.
 
=== Known type attribute values ===
 
==== Blank ====
A blank type attribute usually implies that it is a text node in an outline, using the '''text''' and '''created''' nodes. This is usually the behavior of most outliners and is the default behavior of the OPML Editor.
 
==== RSS Feed ====
The '''type''' attribute is set to string '''rss''', implies following attributes:
* '''text''' - usually, but not always, the title of the feed - is user-modifiable, so should not be used as feed title by applications
* '''xmlUrl''' - the URL of an XML feed
* '''htmlUrl''' - the URL of the HTML representation of the feed (optional)
** Implementation note - Bloglines emits invalid OPML by sometimes including this attribute but leaving it blank [http://tommorris.org/blog/2007/09/01#When:09:07:29].
* '''language''' - the language of the feed (optional)
* '''version''' - the particular type of XML feed:
** '''RSS''' - The [http://opml.org/spec2 spec] lists this as being used for RSS 0.9x and 2.0 feeds
*** MIME type: application/rss+xml
** '''RSS1''' - The [http://opml.org/spec2 spec] lists this as being used for RSS 1.0 (RDF) feeds
*** MIME type: application/rdf+xml
** '''scriptingNews''' - The [http://opml.org/spec2 spec] lists this as being used for Scripting News format feeds
*** This is an edge case. I'm outputting application/rss+xml as MIME type unless anyone has any good argument to the contrary. This is because it should trigger most people's "RSS" mode in their browser, and then their RSS reader should be able to unpick it using whatever parsing magic is contained within.
*** An example scriptingNews feed [http://essaysfromexodus.scripting.com/xml/scriptingnews2.xml], and a [http://www.manton.org/2003/03/scriptingnews_format.html Python parser].
** '''atom''' - In unofficial usage, this is used for Atom feeds of all types
*** MIME type: application/atom+xml
*** [http://www.opml.org/stories/storyReader$5199#randyMorinsComments Dave Winer]: "I don't know what the valid values are for the Atom version attribute. If someone who is an expert on Atom would provide them, and show me that there's some agreement about this from Atom experts, I would be happy to say something about this in the OPML 2.0 spec."
** '''RSS2''' - In unofficial usage, this is used to represent RSS 2.0 feeds only (although, according to the spec, they ought to use '''RSS'''.
* '''description''' - The description field from the linked feed (optional)
* '''title''' - The title of the linked feed (eg. "Engadget") (optional)
** Best behavior with title is to grab the RSS/Atom feed and infer it from that, rather than relying on the OPML file to give it to you.
 
What should be done with an RSS feed node? Since it is almost the primary use of OPML, it would probably be advisable to optimize any conversion effort to deal efficiently with feeds.
 
The '''text''' attribute may list something different from the title of the linked feed, so that ought to be the value of the hyperlink - one may link to the blog "Epeus' Epigone" and set the text field as "Kevin Marks".
 
If the version attribute is present, it should be used to drop in the relevant MIME-type on the link to the feed.
 
Ideally, an OPML-to-XOXO converter would also locate the HTML versions of feeds if the '''htmlUrl''' attribute is not there.
 
Another implementation note for the version attribute: it's a good idea to check for both upper and lower case versions (eg. the standard "RSS" and the lower-case "rss"). Although the values are enumerated in the specification, I'm betting there are probably misuses out there.
 
==== Include ====
The '''type''' attribute in OPML 2.0 is set to '''include'''. Otherwise, the include mode is inferred if the '''type''' is set to '''link''' and the '''url''' attribute ends in ".opml".
 
Ideally, if the '''include''' mode is triggered, the HTML should represent it as a hyperlink to the OPML document, perhaps as follows:
<pre><nowiki>
<li><a href="[url]" type="application/xml+opml">[text]</a></li>
</nowiki></pre>
 
==== Date-time stamp ====
OPML contains a "created" time-stamp, which is generally used in outliners but not in feed readers. The created attribute uses [http://asg.andrew.cmu.edu/rfc/rfc822.html RFC 822] date format. The [[datetime-design-pattern]] could be used to represent it, perhaps with a classname of '''created'''.
 
=== Mapping proprietary extensions ===
OPML is extensible through the use of namespaced elements and attributes.
 
There are some proprietary extensions which it would not be appropriate to map to XOXO. The GrazrScript extension is probably one of those. There is no value in mapping it to XOXO, as it will not serve any purpose. Converters should ignore it.
 
Currently, the following proprietary/non-canonical extensions to OPML can be mapped to XOXO:
* '''grazr:name''' should map to the '''id''' attribute of the containing list element.
* '''bb:rating''' (namespace: <nowiki>http://blogbridge.com/ns/2006/opml</nowiki>) is used by BlogBridge to provide an 'attention rating'.
* '''bb:tag''' should be mapped to a [[rel-tag]], in the same way(?) as the category attribute.
 
=== Preliminary Mapping ===
Currently, I am trying to work on a preliminary mapping from OPML and the internal Frontier outline format (on which OPML is strongly based on, and with which it is compatible. This is unreleased so far, but I put the mappings up so that people can suggest improvements to the semantics.
 
Each of the 'li' elements can, of course, use the compact attribute.
 
The text type:
<pre><nowiki><li>[text()]</li></nowiki></pre>
 
The feed type:
<pre><nowiki><li><a href="[@htmlUrl]" class="feed">[text()]</a> <a href="[@xmlUrl]" class="feed-xml" type="application/xml">RSS</a></li></nowiki></pre>
(The text label "RSS" can, of course, be changed to 'feed' or 'Atom' or any other text label that you wish. The 'feed' class is to enable reverse XOXO-to-OPML)
 
The include type:
<pre><nowiki><li><a href="[@include]" class="opml-include" type="[MIME]">[text()]</a></li></nowiki></pre>
* MIME type still to be determined. I will be asking questions on the OPML mailing list to see if we can get some consensus on what MIME type to use. This may be a bit like opening a can of worms, but we'll see how it goes. --[[User:TomMorris|TomMorris]] 20:08, 10 Aug 2007 (PDT)
 
(Still more to add)
 
=== Test Cases ===
I have started maintaining a list of [http://tommorris.org/pages/opml-test-cases OPML Test Cases] and [http://tommorris.org/pages/opml-tools Tools] for work on OPML-XOXO work. --[[User:TomMorris|TomMorris]] 14:21, 10 Aug 2007 (PDT)
 
=== Notes ===
* [http://rbach.priv.at/Microformats/IRC/2007-08-10#T154821 IRC Log for 2007-08-10]
* [http://copia.ogbuji.net/blog/2005-11-15/I_must_be_#1132141337.5 l.m. orchard's comment on Uche Ogbuji's blog post about XOXO and OPML]

Latest revision as of 18:44, 3 December 2009

XOXO brainstorming

Authors

Example Uses

XOXO Lists and outlines are used for numerous special purposes across the web. This section is here to document both best practices and recommendations.

Blogrolls

Background: See L.M. Orchard's post "Subscriptions Are Attention But What About Blogrolls".

Nearly all blogrolls are already published as XOXO on blog, but there is no obvious way to distinguish the XOXO blogroll from other lists in the content/header/footer of the blog.

XOXO standardizes (see xoxo-profile) the class name "blogroll" for blogroll lists. E.g.

<ul class="xoxo blogroll">
 <li><a href="...">...</a></li>
 <li><a href="...">...</a></li>
</ul>

Note that a blogroll is a superset of a subscription list.

Subscription information

Some blogrolls contain feed information -- it would be nice if XOXO blogrolls could capture this information also. This, in and of itself, would be a nice step up from OPML.

  • An example of OPML to a unordered list w/ expand/collapse folders
Possible XOXO blogs+feeds markup

Here is one example of how you could publish blogs+feeds in XOXO. Note that since a XOXO parser will only treat the first hyperlink as the info for the list item, the blog names and URLs will be parsed, and the feeds will be ignored. In reality, the blogs themselves should contain the necessary auto-discovery links to their own feeds, which is more reliable anyway.

<ul class="xoxo blogroll">
 <li>
  <a href="blogURL1">Blog Name 1</a>
  <a href=".../index.xml" rel="alternate" type="application/atom+xml">RSS</a>
 </li>
 <li>
  <a href="blogURL2">Blog Name 2</a>
  <a href=".../index.xml" rel="alternate" type="application/rss+xml">RSS</</a>
  <a href=".../index.atom" rel="alternate" type="application/atom+xml">Atom</a>
 </li>
</ul>

CSS styling could make this as pretty or not as desired.

See also blog-info-examples, blog-info-formats, blog-info-brainstorming, XOXO Blogroll Format

Wishlists

Background: See L.M. Orchard's post: "I wish it were in XOXO"

Similar to blogrolls, what if we used the class name "wishlist"?

What are the distinguishing features of wishlists?

Is a wishlist item the same as a listing that is looking for an item? See: listing-examples, listing-formats, listing-brainstorming

Tagged Links

This one seems easier, because you could simply use a list of xFolk items, which is recognizable.

Alternatively we could also use the class name "linkroll".

But how far can we successfully take that method (of adding a new class name for each specific use of XOXO) scale and continue working?

Applying "compact", Presentation Caveats

Currently, setting DOM property compact to true in Gecko produces an empty-value compact="" attribute, rather than the valid compact="compact". In order to account for this quirk/bug, the CSS2 selector should be:


ol[compact] { display: none; }

If the XOXO item (represented by li element) contains properties, the application of compact may require more work to provide desired presentation. Since compact applies to the list, not the item, the properties of the item remain unaffected by changing the value of the attribute on the list (which is a peer of the property bag, represented by dl element). For example, consider this XOXO fragment:


<ul>
	<li>select
		<dl>
			<dt>show-title</dt>
			<dd>false</dd>
		</dl>
		<ol compact>
			<li>title</li>
			<li>abstract</li>
		</ol>
	</li>
</ul>

If the desired presentation effect is to only show select when the nested list is collapsed, additional information (like a class name, assigned to li element) is necessary to hide dl element. In CSS3, there is a way to somewhat address it using general sibling selectors:


ol[compact],
ol[compact] ~ dl { 
   display: none;
}

Parsing Properties

  • From HTML spec, the content of both dl, and li can contain block or inline elements.
    • this implies that special properties can include markup.
    • naturally, url, type, and rel properties don't fit into this rule logically, but that's a reasonable exception.
  • First a element specifies text, url, title, type and rel properties
    • If these properties are also defined using dl, they:
      • a. override values, specified in hyperlink
      • b. are ignored -- I (DimitriGlazkov) am leaning toward this choice
  • First dl is treated as a special property set
    • how to escape in case dl is content, not property set?
      • possibly like this:

<ul class="xoxo">
	<li>
		<dl>
			<dt>text</dt>
			<dd>
				<!-- escaped -->
				<dl class="dictionary">
					<dt>term</dt>
					<dd>definition</dd>
				</dl>
			</dd>
		</dl>
	</li>
</ul>

Based on preliminary research, all parsers mentioned in xoxo-sample-code use property bag or dictionary to collect properties, which means that last value specified wins (overrides previously specified). This means that this bit of markup:


<ul class="xoxo">
	<li>
		<a href="http://microformats.org">Microformats</a>
		<dl>
			<dt>text</dt>
			<dd>XOXO</dd>
		</dl>
	</li>
</ul>

Will parse the value of text property as XOXO, not Microformats. Not sure yet whether this this the right thing.

Representing data structures in HTML

A mapping could be made between XOXO and the standard data structures of most programming languages - JSON, YAML, XML-RPC etc. --TomMorris 10:02, 10 Aug 2007 (PDT)

OPML/XOXO conversion

This has been moved to xoxo-opml-issues. –TomMorris 18:44, 3 December 2009 (UTC)