img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

Edward O'Connor <>, 2012-07-31 15:13 -0700:

> While this Change Proposal is both concrete and complete, I intend to
> solicit comments from conformance checker developers which may result in
> testimonials I would like to cite in the Rationale section.

Speaking personally and only with my conformance-checker-developer hat on,
I strongly support this change proposal. I've not talked with Henri about
it yet, but if he were also supportive of it, then it's something we would
implement support for in the sources (on which both the service and W3C Nu Markup Validation Service are based).

Some specific parts of the CP that lead me to express support for it:

1. I agree with the statement in the CP which asserts that the general use
case this CP is attempting to address is an important use case to address.
The use case is valid, and I think we should all work together to try to
find out a way to address it that we can all agree on. This CP seems to me
to be the most viable CP for this issue so far that we actually have a
chance of getting agreement on.

2. The observations in this CP about the need for "granular relaxation" for
this use case are particularly important and need to be considered; I
believe in particular the following statement makes an important point:

  "The markup of large Web applications is typically partly generated from
  code and partly sourced from hand-authored HTML templates. With an
  all-or-nothing mechanism, there's no way to relax the conformance
  criteria for only the portions of the document corresponding to
  user-generated content, while retaining strict requirements on the
  portions of markup from the hand-authored HTML templates.

This CP addresses that particular use case. The meta@name=generator
exception currently in the spec does not.

3. Related to #2, I agree with the following assertion about the positive
effects of this proposed change:

  "We enable engineers of large Web applications to catch markup errors that
  they can do something about, without bothering them about markup errors
  they can't do anything about."

That's something which is of real-world concern to validator developers.
When users attempt to validate documents and end up getting a large amount
of error messages about potential problems which they have no means to
correct directly themselves, we risk having them just give up and quit
using the validator altogether. This is of very practical concern for
anybody maintaining a validator: You want users to keep using your validator
and to have the validator match their real-world needs as much as possible.

Anyway, in summary and as I mentioned in #1, I think this CP provides a
resolution that we have a good chance of getting agreement on among the
people in the group who so far have been unable to reach agreement on it.
So I hope everybody involved can consider it very carefully, with an open
mind.  It's not a perfect solution for the problem. We're not going to find
a perfect solution. But this is the best solution I've seen so far.


Michael[tm] Smith

Received on Wednesday, 1 August 2012 00:58:31 UTC