[SVGMobile12] SVGT12-163: Section 3 conformance criteria

Hello www-svg,

>> I see your point, although I think that 'every sentence which does not
>> contain the word 'must' is not testable' goes too far.
> 
> Oh I didn't mean to imply that. It's just that every statement, to be 
> testable, has to be normatively traceable to a statement to the effect 
> that an implementation has to act as described to be conformant. The 
> definition of the word "MUST" does this, as does a statement like "to 
> conform to this specification, user agents have to follow the following 
> steps: 1. ... 2. ... 3. ...".

Noting that your sample sentence "to conform to ..." doesn't have the
word must, buts ays that the implementation has to do blah to conform,
and then looking at the introduction to this chapter, I see

  Implementations of SVG are expected to behave as though they implement
  a rendering (or imaging) model corresponding to the one described in
  this chapter. A real implementation is not required to implement the
  model in this way, but the result on any device supported by the
  implementation shall match that described by this model.

Which seems to say pretty much what you said, except that it defines
that the result has to be as if the steps were followed, rather than
constraining implementations on the details of their internal design.

To take another example,

  SVG uses a "painters model" of rendering. Paint is applied in
  successive operations to the output device such that each operation
  paints over some area of the output device.

This is easily testable, and is in fact tested, despite not having
"must" or "shall" or "to conform ...have to". With the newly added text

  Element are rendered using a pre-order, depth-first walk of the SVG
  document fragment. Subsequent elements are painted on top of
  previously painted elements.

based on comments from the second last call, this seems to pretty much
cover it for the painters model.

> What I meant by "untestable" is that if a UA acts contrary to that
> statement, it's still technically compliant. There's nothing to test:
> UAs are going to be compliant whatever they do with respect to the
> statement.

So you seem to claim that a breadth-first walk, or a random painting
order, or indeed any other possible result, is equally conformant. This
is pretty stunning - is an actual implementor really going to draw such
a conclusion?

In an effort to try to understand your position, I looked at a
specification you edited. I went for a chapter mid-way through the spec,
one about implementation details, to avoid any possible introductory
verbiage and maximise the chance of finding the type of language you
would like to see.

Looking at
Visual formatting model details
http://www.w3.org/TR/CSS21/visudet.html

10.1 Definition of "containing block"

  The position and size of an element's box(es) are sometimes calculated
  relative to a certain rectangle, called the containing block of the
  element. The containing block of an element is defined as follows:

  [...]

  In paged media, an absolutely positioned element is positioned
  relative to its containing block ignoring any page breaks (as if the
  document were continuous). The element may subsequently be broken over
  several pages.

"are sometimes calculated"? "is defined" (which seems clear to me, but
is not "shall be defined").  "Is positioned"? again, clear to me but not
what you seem to be asking for. "may subsequently be broken" - or may
not? Or any random thing is conformant?

There are six occurrences of "must" in the whole chapter. It seems that
by your reconning,
Visual formatting model details
http://www.w3.org/TR/CSS21/visudet.html
is woefully lacking in conformance criteria and pretty much any
rendering would pass. Yet, apparently, implementors are able to read
plain English like "If there is exactly one value specified as 'auto',
its used value follows from the equality." and figure out what to do.


I would still be interested to hear of actual specific ambiguities in
the SVG rendering model that are likely to cause variant rendering and
could be genuinely improved by a change in wording, however.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 8 December 2005 03:12:55 UTC