Thoughts on @profile

Ian asked me to send in my thoughts on the profile attribute.

I'm the primary developer of Swignition
<http://buzzword.org.uk/swignition/> a tool that aims to parse both the
so-called "lower-case semantic web" and "upper-case Semantic Web". It
includes various modules for parsing microformats and other widely used
"plain old semantic HTML" patterns, plus RDFa, eRDF, GRDDL, etc, pulls
it into a big pot and uses that to output useful stuff. e.g. outputting
vCards which combine data gleaned from hCard and RDFa; or iCalendar
events which contain a mixture of data from hCalendar and RDF/XML.

Swignition's currently on a bit of a development hiatus while I work on
other projects, but has not been completely abandoned.

Anyway, Swignition uses the @profile attribute for a number of purposes.

Firstly, microformats use class names and link types which may already
exist in the wild in some cases. While they're mostly chosen to be
fairly unique, collisions do happen. For example, class="vcard" is
occasionally seen on links to VCF files. In fact, I've even seen this
used on pages which had a genuine hCard on them too.

Including an explicit link to a well-known URL for a microformat profile
provides a disambiguation mechanism. It allows a page to indicate that
when it says class="vcard" it's using the hCard microformat.

In practise, not very many people include the hCard profile in the wild,
so relying on this mechanism to detect hCard usage is not especially
useful, however, Swignition provides a "strict mode", which when enabled
does require the hCard profile to be used. This strict mode does produce
fewer spurious results on pages where accidental collisions occur, so
it's useful to have as a toggle.

Secondly, some microformats patterns have well-documented accessibility
issues. For the last few years the microformats community has been
working at addressing these issues, but work has not been fast. Numerous
different patterns for markup have been proposed, including, for
example:

 <span class="dtstart data:20091117">11 Nov 2009</span>

 <span class="dtstart">
  <span class="value-title" title="20091117">&nbsp;</span>
  11 Nov 2009
 </span>

 <span class="dtstart usetitle" title="20091117">
  11 Nov 2009
 </span>

 <span class="dtstart" title="data:20091117">
  11 Nov 2009
 </span>

I've implemented support for some of these unofficial suggestions, but
with these experimental and not widely used techniques it's been
especially beneficial to have the profile attribute to use as a flag for
toggling behaviour. In these cases I've found it most useful to disable
support for the patterns by default and (even when not in strict mode)
*require* authors to use a well-known profile URI to switch on the
behaviour.

Similarly it supports extensions to certain microformats when particular
profile URIs are found. For example, it supports rel="evil-twin" if a
profile URI of <http://xen.adactio.com/> is found.

Swignition supports GRDDL. If a page uses GRDDL, the parser will
download profiles linked to and inspect them for transformations which
can be run on the page to yield more data. Transformations can be
written in either XSLT1 or RDF-EASE (and I did have plans to allow
Javascript transformations, but libjs doesn't include any DOM support
when run outside the browser).

So Swignition uses @profile in a variety of ways. As it happens, being
forward-looking, it also supports rel="profile" on A and LINK elements,
and HTTP Link headers with rel="profile" too.

Overall I'd recommend keeping @profile for its use in GRDDL, and as a
general purpose flag that user agents can use to trigger particular
processing behaviours. While Swignition does support rel="profile", I'd
recommend against introducing this as a new standard way of indicating
profiles, as is seems a gratuitously different syntax, not backwards
compatible with existing agents.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Tuesday, 17 November 2009 15:08:35 UTC