Re: Blogging needs a whole new BAG...

[Danny Ayers <danny666@xxxxxxxxxxx>]

Hi Bob,
I just read the "chat" minutes and thought it (and you especially ;-) 
raised some interesting points. Good of you to summarise here.

Bob Wyman wrote:

>     Just as "the web" has a TAG (Technical Architecture Group) I think 
> Blogging needs a BAG (Blogging Architecture Group.) I believe that the 
> charter for either the W3C or IETF Atom group should include a task to 
> form a BAG and produce a Blogging Architecture.

Though I see where you are coming from, I'd argue that Blogging 
Architecture and Web Architecture are one and the same. I believe it 
would be most productive for the Atom WG to have a relatively narrow 
scope, covering the details of the format and API specifications and 
best practices relating to them. I do however think it would be in scope 
to carry out some discovery relating to the bigger picture, and if 
necessary recommending the creation of other groups to take on those 
tasks. At present there much speculation but little hard evidence of the 
wider requirements, or at least what there is isn't in a form from which 
clear courses of action can be decided. Whether the requirements are 
specific to the blogosphere or the web as a whole certainly isn't clear. 
But whatever, an Atom WG could act as a foot in the door for future, 
broader work if necessary.

>  
>     * Push vs. Pull: Currently, blogging is all about pull and 
> polling. However, it is clear to many that the current approach simply 
> won't scale. We can't have millions of aggregators polling and pulling 
> from millions of Atom files without introducing massive resource 
> consumption issues.

Speculation. I happen to agree that this does look to be the case, but I 
don't believe there is enough concrete evidence on which to make 
concrete decisions. I certainly hope and expect there to be considerable 
work done on Push and P2P with Atom. I suspect this kind of work is 
essential for the evolution of the web as a whole. But I don't think 
being alarmist about it is in anyone's interests.

> Will W3C be willing to support push-based Atom?

I don't see why not. The Atom format is agnostic. The Atom API may have 
arisen to fulfil the immediate needs of the current polled-HTTP approach 
to syndication, but there is every reason for it to enable other 
approaches.

>  
>     * Pinging: Blogging benefits from the various "pinging protocols" 
> which currently depend on XML-RPC (a non-W3C protocol).

Pings can be implemented using RESTful approaches, there is no 
dependency on XML-RPC. But I do agree that lightweight calls (or 
callbacks) are likely to be extremely useful. The Atom API should 
provide a good starting point for a consistent approach.

>  
>     * Trackback: The "trackback protocol" is popular, provides 
> benefit, etc. however, there are a number of major issues that should 
> be addressed. These issues include the same authentication and 
> signature issues that relate to pings. There are also important 
> architectural issues that should be addressed in order to deal with 
> the problem of trackback-spam. Is it possible/desirable to provide for 
> "trackback aggregators" or trackback services on behalf of blogs? Is 
> Trackback really just a special case of Pinging?

The answer to the last question sums this up as far as I can see: "yes". 
I believe the Atom API can provide a general purpose system that is 
applicable for all kinds of ping.

>     Trackback is a generally useful function that should be supported 
> outside the realm of blogging. A major "architectural" issue with the 
> web has always been the fact that links are uni-directional. Explicit 
> trackbacks are one way of providing the backlinks needed to construct 
> bi-directional links. Presumably, bi-directional links would be 
> generally useful. What, if any, modifications would need to be made to 
> trackback in order to make the facility generally useful? Are there 
> extensions to HTML that should be made in order to record "in-bound" 
> links or to provide a means of pointing to where one would discover 
> in-bound links?

The kind of links you are talking about, HTML hypertext links, are only 
really a special case. There are considerably more versatile forms of 
linking already well-specified, and to varying extents deployed (RDF, 
Topics Maps, XLink). Probably the main reason linking on the web is 
currently unidirectional is that's all the common user agents (HTML 
browsers) support.

>     * OPML: Many blogging applications rely on OPML files as a means 
> of recording and exchanging lists of blogs, metadata about them, etc. 
> There is not, however, a well-accepted definition of how one builds an 
> OPML file (although Danny Ayers, among others, has worked on this 
> issue.) and OPML is not the subject of any serious standardization 
> effort. If OPML use is to grow, we really must see some 
> standardization here. Also, we're seeing the growth of applications 
> that rely on the sharing of OPML files. Thus, do we need to extend the 
> concepts of pinging, trackback, push, etc. to include API and update 
> notification support to OPML file maintenance?

I haven't seen anything done with OPML that could be done just as easily 
and almost certainly in a more interoperable fashion using other 
established standards such as XHTML. The "big tree" ideas sound fun, but 
the tree is an unnecessary restriction. The hierarchical approach is one 
reason why the WWW succeeded and Gopher faded, about ten years ago. That 
quick and interesting applications can be put together using OPML is 
interesting, and suggests that the barrier to implementation of proper 
specifications can be lowered. I've attempted to get something more 
generally useful out of OPML, but its lack of standardisation results 
very quickly in diminishing returns. Frustration ensues...

>     * The role of proxies, synthetic feed generators, systems like 
> PubSub.com, etc. is neither well understood nor defined, however, it 
> is clear that there are today quite a number of these things and there 
> will be more in the future. Effort should be put into at least 
> clarifying the issues related to these intermediary processors and 
> distributors of Atom files.

Yes, yes, yes. In no small part because if RSS gridlock is a likely 
scenario, the use of intermediaries may offer a route around it.

>  
>     * Comment support is provided by many blogs and we're beginning to 
> see issues related to comment spamming, etc. Is there something we can 
> do from an architectural point of view to prevent comment spamming? 
> (i.e. do we need something like an IRTF spamming group?) How do we 
> handle remote commenting and what is the place/role of services like 
> SixApart's "TypeKey" service? Should a "TypeKey" standard be 
> developed? How does the W3C Annotea effort relate to commenting and/or 
> blogs in general?

These are issues which call for examination by a Working Group.

>  
>     * HTTP has limitations that are a true burden in blogging. For 
> instance, there is no server-side support for identifying and 
> retrieving of "fragments" of a resource served by an HTTP server. 
> Thus, you can't say things like "Give me only the entries that have 
> been updated since time XXXX'". Should HTTP be extended to address 
> better the needs of Atom? Should RFC-3229 be extended to define an 
> ATOM specific mechanism for retrieving Atom Fragments?

Did you see the responses on the TAG list relating to Patrick Stickler's 
proposed additional HTTP verbs? The general feeling was that this 
probably wasn't such a good idea. Essentially the same question arose as 
a possible requirement for Semantic Web systems. This isn't a coincidence.

>  
>     * As Atom and blogging becomes more popular, there will be some 
> sites that generate large quantities of Atom formatted data and others 
> that will consume large quantities of it. This raises the issue of 
> binary or compressed formats for Atom data.

One for the Atom WG or the Binary XML folks - but personally I'd say 
gzip is your friend.

>     * Many commercial publishers have expressed an interest in 
> syndication but also express great concern about the various issues 
> related to IPR and usage rights. Is there anything we can do to 
> provide a means to support digital rights management in Atom feeds or 
> systems?

Good question. Another for the WG.

>     * PICS (Platform for Internet Content Selection) provides a means 
> to tag content to facilitate content selection, rating services, 
> filtering, signing and privacy. We need to consider how PICS relates 
> to the world of blogging.

Ditto.

>     * P3P (Platform for Privacy Preferences) was designed with web 
> sites in mind. Does P3P work for the kind of systems that would be 
> developed using Atom, the Atom API, and other blogging components? 
> Does P3P need to be extended to address blogging related issues?

Probably.
(Forgive me for bringing this up, but aren't PICS and P3P already 
available through RDF?)

>  
>     * Various efforts have been made to support "categories" as 
> meta-data in blogs and blog entries. Most have failed. It seems like 
> these efforts should be formally linked to similar efforts such as the 
> ISO Topic Map or the XTM standards. Ideally, any solution for blogs 
> would also work well in non-blog environments. Do we need 
> standardization of things like "subject indicators" or do the existing 
> standards do the job?

Here I would suggest that discussion with Semantic Web people could 
really help. This kind of thing is currently on the table for the SW 
Best Practices group.

>     These are just some of the issues that rise out of the general 
> problem of blogging. Frankly, I think what is really going on here is 
> that in the blogging world, we're experimenting with and defining much 
> more than just blogs. What we're really doing is working out the 
> details of a whole new way of interacting with the web. Now, as we are 
> passing from the stage of initial experimentation to a stage of 
> consolidation behind an initial set of formal standards, I think we 
> need to expand our vision to include the full range of issues that 
> have been raised. We also need to think about how the web-at-large can 
> benefit from what we've learned in the laboratory of blogging.

I agree entirely, but I think it would be better to set clearly defined 
short-term goals than attempt to take on everything at once. The best 
bet IMHO is to work alongside people that are already trying to figure 
out the bigger picture from other directions.

>     As said before, blogging is much more than just a file format and 
> an API. Atom and its API should only be considered the first of many 
> steps in defining how blogging, and this style of web use, are to be 
> pursued in the future. Whatever forum we use to define the first steps 
> on this road should be a forum which will be appropriate for 
> resolution and discussion of the other issues as well.
>     Is the W3C willing and able to deal with more than just the 
> immediate issue of format and API? Is the W3C willing, able, and the 
> best forum to deal with the overall problem of bloggging?
I think the answer to all these questions is probably yes.

Cheers,
Danny.

--

Raw
http://dannyayers.com