- From: Danny Ayers <danny666@virgilio.it>
- Date: Thu, 8 Jan 2004 13:16:52 +0100
- To: <www-tag@w3.org>
I've suggested that Atom [1] could use a Site: HTTP header to provide site info. It's been suggested that this might in some way conflict with the proposed TAG approach, so I thought I'd better check. One of the requirements of the Atom system is to be able to easily discover site services, services that fulfil functions usually found on weblogs : e.g. posting blog entries and comments, the feed for syndication. The preferred form of these services is standard http methods. A way of describing the services has been pretty well worked out in the Atom API [2], based on the common Atom format. An example would be: <link rel="service.post" type="application/x.atom+xml" href="URI for Posting goes here" title="The name of the site."> I've suggested on the mailing list that the services could be advertised using the approach (described at [3]) of using an additional Site: {uri} HTTP header to identify the (conceptual) website. When a GET is done on that URI, an Atom-format file would be offered with the mime type ="application/x.atom+xml" (or similar). Given that the mime type isn't one likely to be used for other descriptions (RDF, RDDL), and that the meaning of "Site:" is the same (a set of resources that form part of what's commonly known as a web site), I believe this to be consistent with the TAG proposal. I do have doubts of my own, but I think they are covered by the idea of Web Site and practical limitations: * the Atom file wouldn't contain an exhaustive list of all resources on site * the Atom file may contain additional information/resources An exhaustive list probably wouldn't be desirable in practice. Additional information shouldn't have side effects, so for a generic "Site Manifest Reader" anything else would appear as comments. This latter case may be significant with Atom, because it does point to the possibility of the Atom file with the "Site:" URI being the syndication feed (e.g. URIs of the 10 most recent blog posts) as well as containing relatively static site metadata. fyi, an (X)HTML <link> element on the site home page with the URI of the Atom data has already found its way into the (provisional) Atom specs. It's been pointed out that if the home page is lousy markup, it's difficult to obtain the URI. Although in most cases an Atom capable system would include generation of the home page, it's still conceivable that it might be unparsable (e.g. an end user template messess things up). Hence interest in alternatives. So, does this all sound consistent with current proposals relating to siteData-36? Cheers, Danny. [1] http://www.intertwingly.net/wiki/pie/FrontPage [2] http://bitworking.org/projects/atom/ [3] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0297.html ---- http://dannyayers.com
Received on Thursday, 8 January 2004 07:25:23 UTC