On Wed, 16 Jan 2008, Kevin Ballard wrote:
quoted text
> 
> My understanding is that normalization is there to help the computer. That
> doesn't give it any semantic meaning, because all normal forms of a given
> string still represent the exact same string to the user.

THAT IS NOT TRUE!

How the hell does the computer know what the string means?

Hint: it does not.

The fact is, the user may use a non-normalized string on purpose. It's not 
your place to say that the user is wrong. Your "undestanding" is simply 
wrong. Two strings are *different* if they are [un]normalized differently.

Really.

The exact same way the word Polish and polish are different, just because 
they are capitalized differently.

quoted text
> The argument for case insensitivity is different than the argument for
> normalization. I certainly hope you understand why they are different
> arguments, or there's really no point in going further.

You do not understand.

In *order* to do case-insensitivity, you generally need to normalize (and 
do other things too - normalization is just *one* of the things you need 
to do).

So if you are a case-insensitive filesystem, then normalization is sane.

But if you aren't, then there is no reason to normalize.

quoted text
> You're right, sometimes the sequence matters. As in key sequences. But we're
> not talking about key sequences, we're talking about strings.

You define "string" to be something totally made-up.

In your world "string" means "normalized". BUT IT'S NOT TRUE!

You define normalization to be a property of strings, without any actual 
backing for why that would be.

The fact is, *looks the same* is very very different from *is the same*.

But you seem to be too stupid to undestand the differce.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html