Re: W3C response to proposed Atom Publishing Format and Protocol (atompub) working group

[Danny Ayers <danny666@xxxxxxxxxxx>]

Hi Eric,

Many thanks, an invitation like this is to be welcomed, whatever 
happens. In this particular case I believe it would be in the interests 
of the Atom project for it to accept W3C support.

Mark's questions below are worth asking, and the comments valid, but 
there's nothing that swings things strongly one way or another. Most of 
the questions are likely to produce similar answers when asked of the 
IETF or W3C scenario.

Mark Nottingham wrote:

> > >  Generally, each participant identified as an individual entity or 
> > > company has a single vote. Decisions are made by consensus and will 
> > > give the possibility to respect the process that the Atom group has 
> > > been able to achieve. Participation in this regard is open to both 
> > > W3C Members and Invited Experts from the community.
>
> This gives a large amount of power to the chosen chair; there may be 
> people who feel excluded.

In what way does that differ from the current situation? I suspect there 
may actually be less perceived exclusion if there is increased 
accountability.

> Even if that can be avoided, the make-up of the Atom community leads 
> me to believe that there will be more Invited Experts than 
> representatives of W3C Members on the WG. Would this be acceptable, 
> from an AC standpoint? In particular, it would be damaging to all 
> concerned if we stalled this effort, only to find out that the AC was 
> not amenable to having what amounts to a non-Member WG formed. Even 
> worse, serious problems could result if the WG came to consensus, but 
> the AC was not happy with that result. Would the Director be willing 
> to prioritise the WG over the AC's advice in such a situation?
>
> Regarding consensus: although I believe they are very helpful in most 
> cases, the W3C's more strict requirements for consensus may turn out 
> to be a disadvantage in the case of Atom. Because syndication has been 
> a contentious topic for some time, and because there are several 
> potential avenues for its development, rough consensus and running 
> code is -- on the face of it -- a more reasonable approach. Can you 
> explain more fully how the consensus process at the W3C would result 
> in a better result, in this particular instance?

I'll leave those for Eric ;-)

> Finally, one of the reasons that the IETF seemed like the appropriate 
> choice was the fact that it's widely regarded as neutral. Some, both 
> inside and outside of the Atom community, perceive the W3C has having 
> a vested interest in the introduction of RDF and/or a relationship to 
> RSS 1.0 (of which you were an author). Whether or not this is true, 
> this perception may make place a cloud over the formation and product 
> of the WG. What steps would you take to dispel this?

Not only are there potential clouds in every direction, there is 
potential sunlight in the very same direction, it all depends on the 
viewer. For example, some perceive the W3C as having a vested interest 
in RESTful and SOAP protocols at the expense of XML-RPC. Shall we ask 
what steps will be taken to dispel that cloud?
Either decisions are made by the group members or they aren't.  Talk of 
specifics is likely to do more to damage neutrality than encourage it.

> > > - W3C Patent Policy: Royalty Free licensing
> > >
> > >   The process around working groups participation helps ensure 
> > > accountability and encourage Royalty Free licensing of the 
> > > technology. RF licensing in particular is an issue we've heard is 
> > > important to the syndication community. More information about this 
> > > policy is available at:
> > >
> > >   http://www.w3.org/Consortium/Patent-Policy-20040205/
>
> As you know, the W3C Patent Policy only provides for RF licensing by 
> Working Group Members. Such an end can be achieved in the IETF as 
> well, if the WG adopts a policy of only accepting unencumbered 
> contributions. It is true that doing this work in the W3C will compel 
> non-participating Members to disclose any claims they may have, but 
> I'm not convinced that this would be a sizeable benefit. Am I missing 
> something? This is IP, so I'm sure I am, but I don't believe there's 
> any inherent weakness in the IETF process WRT IPR.

Or to put that another way, the W3C policy is the same as, or more 
desirable than that of the IETF.

> > > - I18n, Accessibility, Device Independence Support and Coordination
> > >
> > >   The Atom group will benefit from the expertise of these groups 
> > > which in turn will help ensure wide deployment regardless of device, 
> > > language, or ability. Further we expect the resolution of any 
> > > coordination issues arising from these groups will be resolved more 
> > > quickly at the W3C.
> > >
> > > - XHTML Cooperation
> > >
> > >   It is important to understand the relationship between the Atom 
> > > API and the Atom document format. Specifically, we are concerned to 
> > > understand how these might evolve (independently or in-step) and 
> > > whether the API can be used with RDF formats such as RSS1, or W3C 
> > > hypertext formats (e.g. XHTML, or mixed-namespace content). Recent 
> > > W3C work (pre-draft at http://www.w3.org/MarkUp/2004/02/xhtml-rdf) 
> > > on XHTML2 and RDF is combining RDF's metadata approach with XHTML 
> > > document syntax, allowing paragraphs of text to be tagged with 
> > > information about their topic, source, author etc. We suspect 
> > > further discussions (perhaps a Workshop) are needed to fully 
> > > understand how the evolution of XHTML-based approaches relate to 
> > > Atom and blog-oriented systems. Since XHTML with embedded metadata 
> > > can be used to directly encode syndicated content, we believe the 
> > > interdependencies between the Atom API and Atom document format 
> > > deserve some attention, both in chartering the work (whether at W3C 
> > > or IETF) and as the work proceeds.
> > >
> > > We believe the cooperation benefits to be great, and the 
> > > coordination cost will be addressed more quickly if this work 
> > > happens at W3C.
> > >
> > > - XML and RDF experience
> > >
> > >   W3C has years of expertise in definition of content format 
> > > language and model description. XML serialization and RDF model are 
> > > areas of expertise at the W3C. Though when it comes to a content 
> > > model, the organization is pretty agnostic (CSS, XML, RDF for 
> > > example are different models). The Atom group is the one defining 
> > > its content model and syntax.
> > >
> > >   Conversely, Atom would benefit from direct liaisons with these and 
> > > other W3C Working Groups to resolve potential conflicts and 
> > > influence future specifications.
>
> I can't speak for the Atom community, but I've heard a number of 
> reservations about the complexity inherent in the XHTML specifications 
> as well as Semantic Web.  While I personally believe that these 
> technologies have a lot to offer Atom, the community hasn't achieved 
> consensus about adopting them, and I don't believe that the choice 
> should be made for them by fiat. Would a W3C charter include mandated 
> relationships with these groups, or particular requirements for their 
> deliverables?

Correct me if I'm wrong, but I don't think Eric is talking about any 
mandated relationships here. There have been reservations expressed 
about the complexity of XHTML and Semantic Web technologies. There have 
also been strong opinions expressed in favour or XHTML and Semantic Web 
technologies. For the record I believe the current consensus position on 
content is that support is planned for both XHTML and HTML (with perhaps 
the former preferred). On Semantic Web technologies I believe the 
current position is that the syntax will not be RDF/XML, and that 
although an RDF/OWL mapping is considered desirable there is division on 
whether or not it should be normative or informative.

The other groups within the W3C can be seen as sources of information, 
rather good sources in relation to specs such as (X)HTML, RDF, CSS, SOAP 
and so on. Additional information may lead the Atom group towards closer 
integration of a particular technology or towards rejecting it 
altogether. But even if these specific languages and formats weren't 
considerations for the Atom project, it's hard to see how complex issues 
like i18n, accessibility and device independence can be avoided.

> Also, I note that the IETF and W3C have had several successful 
> interactions in the past. What, in particular, is the disadvantage of 
> pursuing these liaison relationships from the IETF, rather than within 
> the W3C? Superficially, it seems that the only reason they'd need to 
> be deep enough to require close co-ordination by the Team is if there 
> were requirements placed upon the WG by them.

I'd like to hear Eric's opinion on that. It might also be worth asking: 
what, in particular, is the advantage of pursuing these liaison 
relationships from within the IETF. Until we have more information there 
doesn't seem to be any massive advantage or showstopping disadvantage 
either way.

> > > -  QA support
> > >
> > > We have noticed that the Atom community already has a lot of early 
> > > implementation and that you have started a testing effort which is 
> > > already impressive. In the context of W3C, this will accelerate the 
> > > advancement of the Atom spec along the W3C Recommendation track. 
> > > It's great to see that a technology is already so mature with a 
> > > well-built quality process.
>
> Would this take the form of W3C Team members contributing to test 
> cases and/or running code? How much of a Team Member's time would be 
> devoted to such a WG? Having professional staff would a substantial 
> advantage.

More information on the likely logistics would be greatly appreciated.

> > > While we recognize the IETF submission, we'd like to hear from 
> > > others within the Atom community regarding the above points, and 
> > > more specifically, their requirements and objectives regarding 
> > > taking this to a standards organization. We'd support proposing a 
> > > W3C Working Group in this area, provided there is support from the 
> > > larger Atom community regarding the points mentioned above and that 
> > > agreement about work areas can be reached with the IETF.
>
> Another concern that I have is the W3C policy of doing substantial 
> technical work in face-to-face meetings. While I agree that this is 
> very productive, it may be too much of a burden for so many Invited 
> Experts, especially considering the W3C's requirement that such 
> meetings be distributed across the globe. I, for example, would likely 
> be participating as an Invited Expert, and would not be able to 
> travel, except when my work plans happen to coincide. The IETF's 
> policy of doing substantial technical work on the mailing list, and 
> not requiring participation in plenary sessions, seems like a better fit.

I imagine that there is some influence on this from the membership of a 
group. But in any case, the Atom meeting in June is in Silicon Valley, 
the proposed meeting at the IETF in August is in San Diego. A 
significant proportion of the Atom community are based in Europe.  

> Because of the issues mentioned above, my perception at this time is 
> that it's more natural to have an IETF WG with liaisons to the 
> appropriate W3C WGs. Would this be workable for the W3C?

There may be advantages in this approach, but I can't see any pressing 
case in either direction based on the arguments above, especially 
without answers to the questions raised. If I remember correctly, in the 
early days of Pie/Echo/Atom the general talk was of 'an organization 
like W3C or IETF' - I don't recall at which point (and by whom) any 
choice was made.

All things equal, it seems to me that the W3C's advance suggests a 
positive inclination from the organisation towards the work of Atom. So 
from the point of view of Atom, I think this is an opportunity that 
shouldn't be missed. We all want things to go faster, to go smoother - 
and here's a fast lane on a road that has actually been on the map all 
along.

Cheers,
Danny.

--

Raw
http://dannyayers.com