To help maybe answer my own question is there any reason why, if the
link tag is not found as previously defined to then check the same
directory specified for an openid.xml file which would be a minimal
atom feed such as:<br>
<br>
<?xml version="1.0" encoding="utf-8"?><br>
<feed version="0.3" xmlns="<a href="http://purl.org/atom/ns#">http://purl.org/atom/ns#</a>" xmlns:dc="<a href="http://purl.org/dc/elements/1.1/">http://purl.org/dc/elements/1.1/</a>"<br>
xml:lang="en"><br>
<title><![CDATA[<XSLT:Blog />]]></title><br>
<link rel="openid.server" href="<a href="http://xsltblog.com/openid-server.app"/">http://xsltblog.com/openid-server.app"/</a>><br>
<modified>2005-06-28T08:38:04Z</modified><br>
<tagline>An ongoing weblog of current topics from the XSLT development community &amp; other<br>
XML/XSLT related news items.
Hosted, maintained, &amp; edited by M. David
Peterson.</tagline><br>
<id>tag:<a href="http://www.xsltblog.com">www.xsltblog.com</a>,2005://1</id><br>
<generator url="<a href="http://www.xameleon.org/">http://www.xameleon.org/</a>" version="0.1">Xameleon</generator><br>
<copyright>Copyright (c) 2005, m.david</copyright><br>
</feed><br>
<br>
This would allow for the existing spec to work as is with the added
insurance policy to allow a request for a specific atom xml file to
override any potential web server issues that serve up other page
formats based on the client.<br>
<br>
This would also add bits of other information pertaining who the user
is, etc... possibly for a richer user experience but thats obviously
beyond the scope of OpenID but within the scope of standards compliance
which will allow for such information to be more easily consumed at the
visiting site.<br>
<br>
Thoughts?<br><br><div><span class="gmail_quote">On 6/28/05, <b class="gmail_sendername">M. David Peterson</b> <<a href="mailto:xmlhacker@gmail.com">xmlhacker@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Oooh... that is definitely something that should be reopened and
evaluated to determine a solution that covers not only HTML/XHTML but,
as mentioned, common data feed formats + SVG, XUL, XAML, and/or any
other XML format which in quite a short space of time will be seen more
and more as the default markup (and as such, namespace) for a variety
of "pages" served up by default when a particular framework (e.g. XAML)
is known to be available on the client. In fact when you download
and install the latest Indigo/Avalon WinFX beta release you are given
the option to set IIS 6.0 to render the XAML version of a particular
page when the client is capable and the server contains the proper xaml
page in the directory requested by this client.<br>
<br>
I realize that the page that is contained at the specified location
does little more than act as a way to locate the proper validation
information and as such can be HTML/XHTML without effecting the rest of
the applications contained on that particular server. But there
are enough justifiable reasons (technical and marketing) for a web
server to be allowed to only serve, for example, RSS and Atom data
feeds, that I believe this will become fairly common place in a fairly
short period of time. In fact services like FeedBurner already
allow the ability to host and serve up your data feeds and as such the
requirement to actually have a public site doesnt exist, instead using
a simple tool to create and post your entries directly to FeedBurner
for publication.<br>
<br>
What then?<div><span class="e" id="q_104c406b15dc56a8_1"><br><br><div><span class="gmail_quote">On 6/28/05, <b class="gmail_sendername">Brad Fitzpatrick</b> <<a href="mailto:brad@danga.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
brad@danga.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Tue, 28 Jun 2005, Mario Salzer wrote:<br><br>> If now HTML/XML parsers check for the presence of <html>,</head><br>> or <body> tags before actually reading out the two <link> tags,<br>
> they deprive themselves from supporting any other XML formats<br>> which were especially designed with 'html compatibility' in mind.<br><br>The reason the head checks were done in Net::OpenID::Consumer was to<br>
prevent people from hi-jacking other people's webpages by leaving
<br>comments/posts (which their software didn't strip) containing link tags.<br><br>But even a regular expression to search for any link tag after we<br>ascertain that the document isn't HTML (say, no <html> or <body> or
<br><head>), that's still kinda lame. I suppose workable, though, if the<br>regexp allows a namespace... but I'd in that case prefer a full-on XML<br>parser so we can match on the /correct/ namespace.<br><br>In practice, though, I imagine OpenID will be tied to HTML/XHTML, and I
<br>think that'll be fine.<br><br>If you have a proposal though that doesn't add tons of complexity for a<br>couple geeks doing XML+XSLT to make their homepage, I'm all ears.<br><br>- Brad<br></blockquote></div><br><br><br>
</span></div>
-- <br><M:D/><br><span class="sg"><br>M. David Peterson<br>[ <a href="http://www.xsltblog.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.xmlblogs.net</a> ]
</span></blockquote></div><br><br><br>-- <br><M:D/><br><br>M. David Peterson<br>[ <a href="http://www.xsltblog.com/">http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net">http://www.xmlblogs.net</a> ]