[uf-discuss] Scraping or parsing?

Thu Mar 1 02:47:42 PST 2007

On 01/03/07, Mike Linksvayer <ml at creativecommons.org> wrote:
>
> On Wed, 2007-02-28 at 13:44 +0100, Danny Ayers wrote:
> > XMDP profiles have already been drafted for many of the microformats
> > (e.g. there's one for hCalendar at [4]).
>
> Possibly stupid question: why profile_s_?  (Or perhaps rather, why
> profile URI_s_.)
>
> Microformats are specified centrally at microformats.org, why not take
> advantage of that?  Adding a profile attribute to <head> will be hard
> enough for some webmasters, why make them think about which one(s) to
> include?
>
> This would also comport with microformat parsers tending to be
> "universal", parsing all microformats.  Imaginary grokMicroformats.xsl
> should be just another one.

Yep, a combined profile would certainly be useful. There is still
value in having multiple profiles in that it allows independent
development (and deployment), microformats at different levels of
maturity can comfortably coexist.

Just as an aside (and I'm open to accusations of "architecture
astronautics" here), if adding a profile attribute is hard for
webmasters, the right answer is to make it easier rather than working
around its absence. The <head> of a HTML document is an important part
of the chain of authoritative metadata [1].

As an analogy, XML-RPC in itself works because there are solid
foundations underneath (HTTP/REST). The fact that it takes rather a
warped view of those foundations means that anything built on top will
be fragile. (Not following the RPC paradigm was a very early design
choice for HTTP [2]). To ensure we can build solid things on top of
microformats, they need to maximimally respect the layers below (HTML,
HTTP, URIs etc). I believe that's the case in principle, only the
practice is lagging a little.

> Finally, consider the single most informative page on the microformats
> wiki -- http://microformats.org/wiki/existing-classes.  Not in anything
> like a profile-style definition list format, but it could be (probably
> as multiple lists).

Thanks - that is a most excellent resource.

Cheers,
Danny.

[1] http://www.w3.org/2001/tag/doc/mime-respect.html
[2] http://www.w3.org/Protocols/DesignIssues.html

-- 

http://dannyayers.com