decoupling from HTML

Tue Jun 28 09:39:57 PDT 2005

While the spec claims that OpenID does not impose its own user
profile format, it is somewhat bound to HTML currently. I wish
the spec would loosen this a bit, and recommend laxer scanning
for:

  <link rel="openid.server" href="http://example.com/in.cgi" />
  <link rel="openid.delegate" href="..." />

HTML is not the only SGML/XML file format which provides <link>
tags. Multiple other formats have this too, and adopted this
tag name solely for the purpose of allowing not namespace aware
parsers to read it out as if it were HTML. Atom feeds make a
good example (though the symmetry may be more accidently in that
case).

If now HTML/XML parsers check for the presence of <html>,</head>
or <body> tags before actually reading out the two <link> tags,
they deprive themselves from supporting any other XML formats
which were especially designed with 'html compatibility' in mind.

Sure, one could still _trick_ regex parsers (like that in the
Perl module) with a Atom feed like:

   <feed> or <whatever>
     ...
     <head xmlns="http://www.w3.org/1999/xhtml" />
     ...
     <link rel="openid.server" href="http://example.com/in.cgi" />
     ...
     <!-- and then even: </head> -->
     ...
   </feed>

But of course, this cannot seriously be the goal! That's why I
ask, that the spec contains a note, which makes that sort of
ugly workarounds unnecessary. If other XML formats already allow
use of HTML-like syntax, this shouldn't be torpeded by needless
checks for <head> or <html> tags - watching out for the angle
brackets and the desired <link> tags seems already safe enough.

If you want a real world example, then think of a HTML-free blog
- one that consists of a single Atom feed only. And if the author
now wants to use this feeds URL (http://blog.atomonly.org/) as
identity for OpenID logins, it would surely help if implementations
were not tied to HTML only.