RE: property value clarification

David Durand wrote:
"No, it should prohibit that behavior. You can always just store bytes
(pardon me, octets), and avoid transcoding. Anyone who is not an expert in
internationalization should in fact avoid transcoding in almost every
situation."

You may be right. I'm not an expert in internationalization.
But storing a 4 byte character set in to a 2 byte character
set like Unicode can result in zero characters. In at least 
one RDBMS I know, a zero byte in the middle of a string will
cause the string to be truncated at that point. So, 
preserving the value can get rather messy, and using it
as a key can be even messier, let alone figuring out
how to do the correct collation. And what are clients
written to use only Unicode to do when they get back a string
in a 4 byte character set? 

But, this is a minor point in the overall discussion.

"Applications can do what they want. If a serer is serving a dead property,
it can't do what you say."

The reason I said it can, is that I am assuming the server 
knows that AgeInYears is an integer. You are apparently 
assuming the server does not know that.

"What about:
<macFilename>   firstload INIT</macFilename>"

Obviously, that's not an integer property. It's a
string property. Whitespace has no significance to
the value of an integer property. But for string 
properties, one would hope that the software doesn't 
throw away any of the characters between the tags. 
However, I've been told that there exist applications 
that do, regardless of whether the XML said it could do 
that or not. That is, they ignore the rules. So, the
best you can do is write the XML instructing the
software not to throw away the white space for at
least that element and cross your fingers.

As my previous e-mail explains, I am assuming the
server knows the data type of alive and dead
properties , and, therefore, the semantics, and you
are probably assuming it does not.

Alan Babich

Received on Sunday, 1 November 1998 22:27:20 UTC