Re: Why publish Design Principles?

I don't think revisiting these will be productive. I favor moving forward and publishing over the few objectors. 

Larry Masinter <masinter@adobe.com> wrote:

>A lot of the discussion of the "Design Principles" seem
>to be rehashing past history of who did or didn't
>use which Design Principle.
>
>I don't think that's too useful. As a "historical artifact",
>we can publish a document with sufficient disclaimer
>that we can at least let some people know what some 
>people tried to use as principles some time, and leave
>it at that. Refining it further NOW doesn't help produce
>a better "historical artifact": after all, documenting
>the past can't be accomplished by rewriting history.
>
>If, on the other hand, there's a desire to publish
>the Design Principles because doing so is USEFUL,
>we should ask:
>
># How do we imagine the Design Principles being used?
>
>One very common reason why standards groups publish
>"Design Principles" documents and "requirements" 
>documents and "goals" documents, is that such documents
>are provided to the community as benchmarks against
>which we expect review of the target document to
>be judged.
>
>So, we could work toward publishing a "Design Principles"
>document against which we expect community review:
>do these principles apply, NOW, to the document that
>we are asking the community to review?
>
>Can we document our goals -- even if they are 
>incomplete, inconsistent, not entirely agreed upon --
>in a way that will be useful to reviewers in the
>review process?
>
>If that's the goal, then we should stop talking about
>the "Design Principles" in the past tense -- what were
>they, whether they were applied during arguments, etc. --
>and instead focus on the present and future.
>
>Going forward, starting today, what Design Principles
>do we want from the HTML 5 specification? And does
>the specification we have match those design goals?
>
>I think, for such a document to be useful, it would help
>to combine it with much of the material now contained
>in Section 1 of the HTML 5 specification -- which lists
>many but not all of the goals that the group or the
>editor or authors wish.
>
>I will add that I don't think agreement on design goals
>is completely NECESSARY. It is always the case that
>different groups in a standards process may disagree
>about goals, or at least about priorities, and the
>standards process is one of discovering compromises
>that allow win-win: that all sides accomplish enough
>of their goals to be satisfied, even if goals don't
>agree.
>
>Finding a common technical solution to disparate goals
>is the heart of standards work.
>
>So let's not hold up publishing a useful document because
>there is not 100% agreement on Design Principles.
>If there are or were differences, document them, note
>the differences, ask the reviewer/reader to determine
>if the result was reasonable, accomplished multiple
>disparate goals in a fair manner, and move on.
>
>Larry
>--
>http://larry.masinter.net