W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > May 2002

another charmod comment

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 24 May 2002 14:00:18 +0100
To: <w3c-rdfcore-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDAEAJCEAA.jjc@hplb.hpl.hp.com>

This feels like a personal comment, but I would be happy if others in
the WG wished to support it.


Charmod does not conform with itself.

This is intended as an issue with sections 1 and 2
concerning the scope and applicability of charmod,
and I apologize for the rather smartass way of
articulating it.

The exposition of the issue follows the mathematical
style known as "reductio ad absurdum", the contradiction
being the above.

A particular non-conformance is that charmod
puts no obligations upon implementors of charmod.
It, does, of course, indirectly place many obligations
on implementors of other W3C recommendations.
An argument that charmod will have no (direct) implementors
would be disingenious. e.g. I would expect/hope library
writers to provide a function that checks that
unicode strings are in normal form c and do not
start with a composing character.
Such an implementor would be able to claim charmod
conformance without having been specifically obligated with

[I] Specifications and software MUST NOT assume a one-to-one mapping
between character codes and units of displayed text.

since charmod has failed to say that implementations of charmod must

[S] Every W3C specification MUST ...
specify that implementations MUST conform to the requirements applicable
to software,

I find a similar problem when drafting text
for the current round of RDF recommendations.
Charmod is framed such that for charmod conformance
a W3C recommendation must have a dictatorial relationship
with its implementators. The RDF recommendations
are more relaxed about their power. They define
RDF documents and their meanings. They do not
indicate what implementators should do, nor do they
tell content writers what to do. It is difficult
to keep reinterpreting the requirements of charmod
into this less confrontational style of recommendation.
This is made more difficult by charmod's own
confrontational style, and expectation that
other recommendations share such a stylistic

I believe that the charmod editors are trying to
say something that is both meaningful and has my
I fear that the framing of the scope of charmod
in sections 1 and 2 has not done justice to the
range of recommendations produced by the W3C
nor the range of different relationships
between recommendations and their users (both
implementors and content producers).

Received on Friday, 24 May 2002 09:00:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:12 UTC