decoupling from HTML

Tue Jun 28 11:43:14 PDT 2005

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>,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 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20050628/0dbbc7b1/attachment.htm