Peter continued:
> Indeed: e.g. that is true for the Unicode 1.0 Name property. My question,
> though, is whether there are some properties that are informative because
> they may be typical for most languages but not true for all. It was always
> my impression that that was the reason for case mappings having been
> informative. Was I wrong in that assumption?
No, you are probably right. Everybody knew from the start (of Unicode)
that case mappings were going to have exceptions. In the absence of
a Character Property Model to guide thinking about how to pigeonhole
things, that turned into an implicit assumption that case-mapping as
a whole should be informative, since we knew that there were going to
be locale-based exceptions for a few well-defined cases.
Recently, it became clearer that the case properties themselves and
the default case mappings had all kinds of firm implications for
many processes that people were implementing, and that it was
inadvisable to keep on saying that case mapping in toto was
informative. This led to the switchover to say that all of this
was normative, together with the formal SpecialCasing.txt way of
enumerating the exceptions.
Offhand, I can't think of any other instances of properties that
were explicitly labelled "informative" because of language-specific
behavior. These are *character* properties after all, and the
characters themselves are not language-specific. I suppose it would
be possible to manufacture another instance comparable to case mapping,
but it would probably be rather odd and presumably wouldn't apply to any
existing property lists in the Unicode Character Database.
>
> The real issue is that I'm trying to find ways to explain to someone why
> there are distinctions between normative and informative behaviours and
> properties.
That's easy. Just as for any Dad responding to the kid's "Why is...., Daddy?"
questions, you ultimately end up giving the ultimate answer: "Because
that's just the way it is." ;-)
>
> Which isn't really helpful for my purposes here, which are didactic: "It's
> normative because conformant implementations have to follow it, and they
> have to follow it because it's normative."
Well, not exactly. "It's normative" *means* that xyz. But "It's normative"
*because* the Unicode Standard says so, which in turn is because the
UTC voted that it be so.
*Why* they voted so may be an interesting historical question in
particular instances, but it may be beyond the necessities of
didactic explanation. A little bit like asking why cardinals are
red and bluebirds are blue, when you get down to it. Maybe there
actually *is* a real reason (or reasons) for that, but it is probably too
complicated to figure out, and ultimately besides the point for
people who just need to be able to distinguish cardinals from bluebirds.
--Ken
>
>
> >Because no one is yet convinced that the specifics of either are
> >so widely agreed upon that the UTC would want to make
> >some strong claim about conformance to the particular properties
> >and their values for implementations of the behavior.
>
> Now that works.
This archive was generated by hypermail 2.1.2 : Fri Jul 06 2001 - 00:17:18 EDT