Re: Draft TAG Finding: Consistency of Formatting Properties

Some more comments on 

    http://www.w3.org/2001/tag/doc/formatting-properties.html
    (version of 25 July 2002)

1) The heading of the document looks a bit like that of a WD, in
particular because it has a "previous version" link. But unlike WDs,
it has no "this version" link, so it is not immediately clear how to
cite it.

2) Abstract. The abstract gives as the main reason for promoting a
common vocabulary the fact that XML vocabularies are being combined.
However, I think ease of use and ease of implementation are more
important reasons. Even when XML vocabularies are not combined (e.g.,
if an SVG and an HTML document are displayed one after the other,
instead of at the same time) or when the vocabularies are not
expressed as XML element & attribute names (e.g., when formats are
based on SGML or are proprietary), it still makes sense to use the
same formatting terms, unless there is a reason not to.

3) Section 1, par. 2. Why is it "imperative" that there is a common
set of properties? I agree that it is useful, but why is it necessary?
The text further down hints at the inheritance of properties, but that
only plays a role in very few situations (see below).

4) Section 1, par. 3. "[...] document that consists of XSL Formatting
Objects, XHTML table mark-up, SVG diagrams, and MathML equations." Such
a document will probably never exist.

Indeed, I believe it is an architectural principle, that the TAG
hopefully one day puts in writing, that XSL-FO elements are at a
different semantic level than (X)HTML, SVG and MathML, and that it is
possible to transform the latter three into the former, but that
putting them in the same document would be counter to the goals of the
semantic Web. In particular, W3C promotes (X)HTML, SVG and MathML as
permanent repositories of information and we expect them to be found
on Web servers, but we don't expect XSL-FO's to be used for anything
else than as a volatile format, that only exists in the milliseconds
between the formatting and the printing of the results.

I suggest to fix that sentence by omitting XSL-FOs, or to find a
different example.

5) Section 1, par. 4 & 5. It might indeed be the designer's wish that
certain things in the text (encoded with HTML or XHTML, to stay within
W3C technology) visually match things in the included graphic (encoded
with SVG). But since the rendering models for text and for graphics
are quite different, it is simplistic to assume that that can be done
with inheritance. For starters, the most important aspect, the size,
is not an inherited property, but a derived aspect that follows from
certain other properties. The color of the text *is* specified by a
property, but it is likely that it is not the text of the graphic that
the designer wants to have that color, but the lines and curves. He
might also want the background color to be the same, but the
background is typically not inherited, but is made transparent,
because that matches better what the designer expects.

I believe that the real reason for wanting a common vocabulary *is*
related to that example, but it is not inheritance that is the key.
Rather, it is the designer's wish to specify the commonalities of the
styles in a single place (i.e., a single style sheet). That means that
it is not strictly necessary that the vocabularies are the same, but
it does help the designer with learning and with avoiding mistakes.

Indeed, often the vocabularies cannot be completely the same, and the
designer also doesn't expect them to be, but they can be similar.
E.g., to make a graphic and a text match, the designer might use
'font-weight' to get thicker stems for the letters of the text and
'stroke-width' for thicker lines in the graphic. An example of
"similar" terms could be this: the conceptually related properties
'border-width' and 'stroke-width' both use the word "width." This
makes the vocabulary consistent to a human, but clearly there is no
formal, machine-readable relation between them. At least not until AI
makes another big leap forward...

5) Section 1. The section talks about vocabularies, but apparently
limits that to properties & values. In the example of an SVG graphic
linked from and HTML file (or physically included in it, as in this
section), what is probably much more important to the designer is the
vocabulary that is used for the selectors. And in general, if the two
formats look (vaguely) the same (as many XML-based formats do, of
course, by virtue of being strewn with angle brackets) then it makes
sense to expect that you can use the same binding mechanism (i.e.,
selector syntax) for both.

6) The article talks about a "common vocabulary" and, although it
doesn't say so explicitly, it seems to imply that there should be only
one. I don't think that follows. All that the example shows is that it
is good for the designer (and the implementer) that they can apply the
same vocabulary to many situations. In the example of an SVG graphic
that is used by an HTML text, it is convenient for the designer that
he can use CSS (i.e., CSS-style selectors and CSS properties) for
both. But it is not the fact that there is only one style language
that is important, but the fact that he can use the one he knows (or
likes) in both cases.

Indeed, there is much to say for a small number of different style
languages. Not all people are the same, not all projects are set up in
the same way, and CSS may not be the best style language in all cases.
Indeed, we can replace that "may" by an "is," because we *know* that
CSS is not always enough. The selectors and properties of CSS are not
enough to style a document that is expressed in RDF, for example. To
render such low-level, abstract information in a useful way, you may
need to include XSLT or Perl in the styling process, and maybe it is
even more convenient in that case to produce XSL-FOs directly, rather
than go through an intermediate format and a CSS style sheet first.

7) Section 1, par. 7. This paragraph contains an important point, that
merits more emphasis. It is indeed very bad when two very similar
terms, such as 'font-family' and 'fontFamily' occur in the same
context (i.e.,  in the same style sheet). That invites errors by
designers and bugs by programmers.

Indeed, such a close likeness is much worse than having two completely
unrelated terms for similar concepts, such as 'font-family' and
'svg-text-font'.

This section also points to another possible source of inconsistency,
which is much harder to pinpoint. We feel intuitively that using
'fnt-size' and 'lineEnding' are inconsistent on three counts, even
though they have nothing to do with each other: the syntax is
different (hyphen vs capital) and the choice of words as well (noun vs
gerund and abbreviation vs full word).

That is why the CSS WG has prepared a document[3] (meant to be
published as part of the CSS syntax module[4]), that talks about
precisely this. Maybe it should be linked from the TAG article, or
paraphrased in it.

[3] http://www.w3.org/Style/Group/css3-src/css3-naming
[4] http://www.w3.org/Style/Group/css3-src/css3-syntax

8) Section 2. It is nice to see the cooperation between SVG, XSL and
CSS called out explicitly, but it looks a bit out of place in a
document that purports to give a timeless (well, let's say long-term)
architectural guideline. Maybe it would read better if it was phrased
differently: as an example or a case study of historical interest.

9) Section 3. The conclusion reuses the word "consistent," but it
still hasn't been defined. Section 1 contained some reasons for
wanting consistency and some examples; section 2 is a case study; but
the section that tries to define what "consistency" means is missing,
it seems.

Of course, it is not possible to define "consistency" as rigorously
as one of our Recommendations might define "well-formedness error,"
but some hints about where to look for its meaning would be good. I
would expect at least some philosophizing about:

  - "consistency" is in the eyes of the beholder, it depends on what
    he has seen before and on the abstract model that is presented to
    him. E.g., If the concept of color is introduced in some
    specification with references to RGB monitors, then people
    probably expect different property names & values than when color
    is introduced as a spectrum of radio frequencies.

  - consistency not only exists between similar concepts used in
    different environments, such as color used in CSS and color used
    in the DOM, but it also applies to different concepts in the same
    environment, such as between color in the DOM and methods in the
    DOM. The former might lead you to choose the name "border-color,"
    while the latter might suggest "borderColor". There are no hard
    and fast rules; the best you can do, probably, is ask a random
    sample of people and use statistics.

10) Section 3. Another important word in this section is
"unnecessary." That word is probably even more important than
"consistent" itself. Consistency is not a goal, it is a means to an
end. And that end is first of all ease of use, and secondly ease of
implementation. A "necessary inconsistency" can therefore exist if the
"consistent" term would lead to reduced ease of use.

There should probably be some section or paragraph that mentions this.
The fact that ease of use is the reason behind the preference for
consistency is, of course, implicit in section 1, but the link from
section 1 to the word "unnecessary" is not made explicit.

11) Hmm, these comments are longer than the article itself. Does that
suggest something about the article? Maybe even that "consistency of
formatting property names" is an interesting example of *something*,
but not an architectural principle in itself?



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 9 August 2002 14:43:30 UTC