- From: Babich, Alan <ABabich@filenet.com>
- Date: Sun, 1 Nov 1998 19:27:44 -0800
- To: "'David G. Durand'" <dgd@cs.bu.edu>, w3c-dist-auth@w3.org
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