decoupling from HTML

M. David Peterson xmlhacker at gmail.com
Tue Jun 28 11:58:48 PDT 2005


Fair enough. :)

On 6/28/05, Brad Fitzpatrick <brad at danga.com> wrote:
> 
> Mostly not a problem. We could debate it for months but in the end people
> would still only use HTML.
> 
> If anybody besides a few uber dorks start using non-HTML identity URLs,
> then we can figure out the best for those sites to declare their OpenID
> server. Oh, but by then there will be a large installed base of OpenID
> consumers that won't understand! (shock) So those early adopters will
> have to wait it out, as they're good at anyway.
> 
> This is also why Net::OpenID::Consumer is bound to http and doesn't even
> accept https (would be a one character fix to change). I know there are
> enough consumers out that that won't do/want to do https, so let's just be
> realistic and say OpenID works for http and html.
> 
> Neighborhood pessimist,
> Brad
> 
> On Tue, 28 Jun 2005, M. David Peterson wrote:
> 
> > So is this a problem left unsolved or is it seen as simply not a 
> problem?
> >
> > On 6/28/05, Brad Fitzpatrick <brad at danga.com> wrote:
> > >
> > > We'd previously discussed a "magic" like that (cookies.txt, 
> favicon.ico,
> > > etc) but decided against it.
> > >
> > > Plus we're not going to let the OpenID core creep into public profile
> > > exchange. Private profile data might be an extension, outside the
> > > core. But public stuff, absolutely not.
> > >
> > > - Brad
> > >
> > > On Tue, 28 Jun 2005, M. David Peterson wrote:
> > >
> > > > 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:
> > > >
> > > > <?xml version="1.0" encoding="utf-8"?>
> > > > <feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="
> > > > http://purl.org/dc/elements/1.1/"
> > > > xml:lang="en">
> > > > <title><![CDATA[<XSLT:Blog />]]></title>
> > > > <link rel="openid.server" href="
> http://xsltblog.com/openid-server.app"/>
> > > > <modified>2005-06-28T08:38:04Z</modified>
> > > > <tagline>An ongoing weblog of current topics from the XSLT 
> development
> > > > community &amp; other
> > > > XML/XSLT related news items. Hosted, maintained, &amp; edited by M.
> > > David
> > > > Peterson.</tagline>
> > > > <id>tag:www.xsltblog.com <http://www.xsltblog.com> <
> http://www.xsltblog.com> <
> > > http://www.xsltblog.com>,2005://1</id>
> > > > <generator url="http://www.xameleon.org/" version="0.1
> > > ">Xameleon</generator>
> > > > <copyright>Copyright (c) 2005, m.david</copyright>
> > > > </feed>
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > Thoughts?
> > > >
> > > > On 6/28/05, M. David Peterson <xmlhacker at gmail.com> wrote:
> > > > >
> > > > > 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.0to 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > What then?
> > > > >
> > > > > On 6/28/05, Brad Fitzpatrick <brad at danga.com> wrote:
> > > > > >
> > > > > >
> > > > > > On Tue, 28 Jun 2005, Mario Salzer wrote:
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > The reason the head checks were done in Net::OpenID::Consumer 
> was to
> > > > > > prevent people from hi-jacking other people's webpages by 
> leaving
> > > > > > comments/posts (which their software didn't strip) containing 
> link
> > > tags.
> > > > > >
> > > > > > But even a regular expression to search for any link tag after 
> we
> > > > > > ascertain that the document isn't HTML (say, no <html> or <body> 
> or
> > > > > > <head>), that's still kinda lame. I suppose workable, though, if 
> the
> > > > > > regexp allows a namespace... but I'd in that case prefer a 
> full-on
> > > XML
> > > > > > parser so we can match on the /correct/ namespace.
> > > > > >
> > > > > > In practice, though, I imagine OpenID will be tied to 
> HTML/XHTML,
> > > and I
> > > > > > think that'll be fine.
> > > > > >
> > > > > > If you have a proposal though that doesn't add tons of 
> complexity
> > > for a
> > > > > > couple geeks doing XML+XSLT to make their homepage, I'm all 
> ears.
> > > > > >
> > > > > > - Brad
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > <M:D/>
> > > > >
> > > > > M. David Peterson
> > > > > [ http://www.xsltblog.com/ ][ http://www.xmlblogs.net ]
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > <M:D/>
> > > >
> > > > M. David Peterson
> > > > [ http://www.xsltblog.com/ ][ http://www.xmlblogs.net ]
> > > >
> > >
> >
> >
> >
> > --
> > <M:D/>
> >
> > M. David Peterson
> > [ http://www.xsltblog.com/ ][ http://www.xmlblogs.net ]
> >
> 



-- 
<M:D/>

M. David Peterson
[ http://www.xsltblog.com/ ][ http://www.xmlblogs.net ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20050628/4329d7ef/attachment.html


More information about the yadis mailing list