Talk:Manufacturing data: Difference between revisions
(It might be better to use UTF-16 rather than either UTF-8 or acsii.) |
No edit summary |
||
| Line 14: | Line 14: | ||
:It might be better to use UTF-16 rather than either UTF-8 or acsii. This would mean that every character from the base plane of Unicode could be expressed using exactly two bytes and every character from any other plane of Unicode could be expressed using exactly four bytes. Maybe the tags should be 16 bytes each? Eight bytes for four UTF-16 Unicode characters, six bytes for three Unicode digits (U+0030 to U+0039) in UTF-16 format, to express a data length of 0 .. 999 words each of two bytes, and two bytes for a checksum of the tag. The data section would also have an additional two bytes as a checksum of the data section. This would take more bytes for tags and maybe more bytes for the data depending upon the nature of the data. However, this is a "design it now, apply it for a long time" situation so maybe it is worth doing. |
:It might be better to use UTF-16 rather than either UTF-8 or acsii. This would mean that every character from the base plane of Unicode could be expressed using exactly two bytes and every character from any other plane of Unicode could be expressed using exactly four bytes. Maybe the tags should be 16 bytes each? Eight bytes for four UTF-16 Unicode characters, six bytes for three Unicode digits (U+0030 to U+0039) in UTF-16 format, to express a data length of 0 .. 999 words each of two bytes, and two bytes for a checksum of the tag. The data section would also have an additional two bytes as a checksum of the data section. This would take more bytes for tags and maybe more bytes for the data depending upon the nature of the data. However, this is a "design it now, apply it for a long time" situation so maybe it is worth doing. |
||
''Jim:'' no one uses UTF-16 anymore. We *don't* want to carry extra conversion tables and code for another unicode format, when UTF-8 is already there. If we do Unicode at all, best it be the same everywhere. The tags can easily be restricted to be ASCII and |
|||
stay one byte (and ascii is part of UTF-8; not true for UTF-16). |
|||
The wireless mac number: I presume this is the only location for the MAC address: there is no mac address in the wireless logic itself? I don't believe in dupicating information that may become inconsistent. What is the format of this string? (presuming |
The wireless mac number: I presume this is the only location for the MAC address: there is no mac address in the wireless logic itself? I don't believe in dupicating information that may become inconsistent. What is the format of this string? (presuming |
||
| Line 24: | Line 29: | ||
user-interface by using iconic representations, both to avoid the manufacturing headaches and because the machines are often being used by kids/parents not yet literate. |
user-interface by using iconic representations, both to avoid the manufacturing headaches and because the machines are often being used by kids/parents not yet literate. |
||
Keyboard types, however, are very important to know (and while are usually related to language, they aren't necessarily a one-to-one mapping). There are actually 2 pieces to |
Keyboard types, however, are very important to know (and while are usually related to language, they aren't necessarily a one-to-one mapping). There are actually 2 pieces to |
||
this: the physical layout of the keys (physical size and position of keyboards), of which there will be relatively few variations (but there will be some variation), and how the keys are labeled (a silkscreening like process). There will be many, many of those. |
this: the physical layout of the keys (physical size and position of keyboards), of which there will be relatively few variations (but there will be some variation), and how the keys are labeled (a silkscreening like process). There will be many, many of those. |
||
But you want to have both pieces of information. |
But you want to have both pieces of information. |
||
Revision as of 14:45, 15 September 2006
- Mitch Bradley approves with the qualification: All items marked TBD must be resolved.
- Ivan approves, same qualification as above.
- Ray <approval needed>
- Ron <approval needed>
- Richard <approves>
- Jim <approval needed> comments:
Add to goals: flexibility; there will be many keyboard variants, possibly a number of other variants of the base machine, with time.
I think either only text should be allowed, or if non-text values are essential and allowed, a type field should be added to the tags.
Should text be UTF-8, rather than ascii?
- It might be better to use UTF-16 rather than either UTF-8 or acsii. This would mean that every character from the base plane of Unicode could be expressed using exactly two bytes and every character from any other plane of Unicode could be expressed using exactly four bytes. Maybe the tags should be 16 bytes each? Eight bytes for four UTF-16 Unicode characters, six bytes for three Unicode digits (U+0030 to U+0039) in UTF-16 format, to express a data length of 0 .. 999 words each of two bytes, and two bytes for a checksum of the tag. The data section would also have an additional two bytes as a checksum of the data section. This would take more bytes for tags and maybe more bytes for the data depending upon the nature of the data. However, this is a "design it now, apply it for a long time" situation so maybe it is worth doing.
Jim: no one uses UTF-16 anymore. We *don't* want to carry extra conversion tables and code for another unicode format, when UTF-8 is already there. If we do Unicode at all, best it be the same everywhere. The tags can easily be restricted to be ASCII and stay one byte (and ascii is part of UTF-8; not true for UTF-16).
The wireless mac number: I presume this is the only location for the MAC address: there is no mac address in the wireless logic itself? I don't believe in dupicating information that may become inconsistent. What is the format of this string? (presuming it is a string).
I'm not sure language is appropriate in the area at all. What is this going to be used for?
The software load has a default locale already, and multiple languages may be supported by a single software load. We've been working hard to not have to localize the BIOS user-interface by using iconic representations, both to avoid the manufacturing headaches and because the machines are often being used by kids/parents not yet literate.
Keyboard types, however, are very important to know (and while are usually related to language, they aren't necessarily a one-to-one mapping). There are actually 2 pieces to this: the physical layout of the keys (physical size and position of keyboards), of which there will be relatively few variations (but there will be some variation), and how the keys are labeled (a silkscreening like process). There will be many, many of those. But you want to have both pieces of information.