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?<br><br><div><span class="gmail_quote">On 6/28/05, <b class="gmail_sendername">Brad Fitzpatrick</b> <<a href="mailto:brad@danga.com">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>
-- <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> ]