what's wrong with CC/PP

Johan Hjelm wrote:
>as chair of the WG, I would like to have more detailed comments. What do
>you consider overdesigned, and why? Do you have suggestions for alternative
>mechanisms? If you can make capabilities negotiation simpler without
>creating a separate protocol, I would like to hear how. 

I'm happy to provide more detailed comments, but I should warn you up front
that these comments are more about the scope of the project envisioned and
the toolkits chosen for building it rather than technical detail about how
the protocol should be constructed.

While I realize that the WG is doing its best to balance a lot of complex
needs, there are some problems inherent in such an approach.  The
Requirements Draft in its current form reads like an enormous
design-by-committee creation, if not an outright Frankenstein's monster.
It seems that the project of reconciling WAP, Conneg, television broadcast,
and the W3C's dream of CC/PP is given higher priority than the creation of
a usable standard.  

The toolbox chosen for building CC/PP - RDF and RDF Schemas - deserves a
closer look.  While RDF is admirably suited for property set description,
making it a good match, it is not exactly well-loved.  RDF is regularly
ridiculed (outside the W3C) for making simple things complex, and for doing
far more work than the project actually required.  RDF Schemas has similar
problems, and worse, has been in a year-long limbo as a proposed
recommendation.  Implementation has been minimal - commercial focus appears
to be on the XML space at present.

P3P, proposed as a privacy mechanism, is in last call for the next two
months at least and probably has a few more phases to go through before
completion.

The Requirements Listing describe a single large protocol, that sounds like
it will appear as one large block, love it or leave it, and the end of the
process.  "Flexibility, extensibility, and distribution" are the executive
summary of requirements - simplicity and usability are nowhere to be found.  

My hope for CC/PP is that it will be widely available and easy to set up
for the many things that it will be used to manage.  The current CC/PP Note
is a pleasant 13 pages, and its exchange protocol 18 pages, but the
Requirements draft is already 36.  Reading the current requirements draft,
I'm deeply concerned that CC/PP will produce a set of tools so large and/or
complex that implementation is delayed or postponed indefinitely.

There are several things the WG could do to minimize these dangers without
throwing everything out and starting over:

1) Make it very clear early on - in the Executive Summary, in fact - who
exactly is going to be managing these profiles.  Is this a task for
'ordinary' Webmasters, or a task for sysadmins, or something that will
require systems integrators and others?  The image of the "Desperate Perl
Hacker" didn't keep all complexity out of XML, but it helped chop off some
potential problems.

2) If you're going to use RDF and RDF Schemas for this critical piece of
infrastructure, make sure that they're cooked.  That may involve pressure
within the W3C, or it may involve (Yikes!) defining the subset of RDF
schemas CC/PP developers actually need, if such a thing is possible.
Although P3P is less integral to the project, it also needs to be stable
and widely implemented for this to work.

3) Don't try to solve every problem perfectly with the first round of
solutions. The requirements document hides a lot of those problems in
Appendices 2 and 3.  Make it clear that the requirements in Section 4 are
normative, but that the requirements in Appendix 2 are for information
only.  If all I had was Section 4, I'd be much less concerned about this
project.

4) Accept early on that this development may have to go through a number of
rounds to achieve its final goal, and plan for that.  Loosely coupled and
even incomplete systems may scare some folks, but they provide more room to
move in the future.  

5) Apply Occam's Razor wherever possible.  Make simplicity an explicit goal
someplace in this document so the committee has some firm grounds on which
to say 'no' to additional features.

These are probably not the technical answers you were looking for, but
these are pretty much my concerns for now.  I'll have more technical
responses when this moves beyond the requirements phase.

Thanks!

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Received on Tuesday, 7 March 2000 10:38:52 UTC