This is true in more places than software. Heck, even signing a check involves rendering a name in ink on paper, which is a restriction for some names I imagine.
Sure its true people have different renderings for their name. So choose one that fits into the software form you're filling out. Not rocket science.
Is there any requirement that one's signature be a handwritten version of the printed version of one's name?
My signature is pretty legible at least if you already see my name in print, but I know lots of people who sign a squiggle. Your name could be ʤᔙ but you still might sign it ᠼ and I doubt anybody would care.
In some cultures a signature is somewhat like a signat-ring, a written emblem not necessarily related to alphabetic sequences. An 'X' for instance, signed on a contract by an illiterate and countersigned by a witness (well that was alphabetic but you get the idea). I knew a fellow from Bangalore who's signature was a graphic, some symbol written above a line and some letters below the line.
I'm told the squiggle is actually better than a legible signature. The legible signature is something you were trained to do following rules, and thus can be forged by someone else following the same rules. The squiggle is you, and so the existence/absence of some loop is enough to show a forgery and thus a forger has to memorize the entire thing with no rules to help.
I'm not qualified to state if the above is true, but I like to believe it is.
Also, if you have an elaborate squiggle, and you write it fast, it makes it very difficult to copy since the forger needs to write it quickly as well to get the same pen stroke results.
In Japan some places require me to sign my name with the exact same way than it's written in my passport using block letters. Normally I'd just write a cursive, stylized version (without my middle name).
Some other names allow stylized signatures, but then they require that the signature must be almost exactly the same every time I write it. Again, not something I'm used to.
This, of course reflects the fact that the Japanese don't use signatures to sign contracts. They use personal name stamps. The requirements make sense if you think your signature as a "name stamp that's written manually".
Of course, signatures are not names, they have extra cultural, societal and legal baggage, but... just a data point that might be interesting.
There was a minor kerfuffle a few years ago because Obama was considering someone for Secretary of Treasury whose signature (which would have appeared on all American bills) was just five or six loops. It bore no resemblance to his name. He just apparently decided that was going to be his signature, and that's what he used for most of this adult life.
I have really terrible handwriting, whenever I sign a document it literally is just some random continuous line. It's never been an issue. Nobody seems to care. You could probably make a smiley face and never have an issue regardless of the importance of the document.
Often the schema is already enforced - e.g. in healthcare you'll find that somebody else has already normalized the wonderful world of names down to two Unicode strings called last and first. Names that don't fit that schema will be coerced by this wonderful technology called "an admissions clerk".
The DICOM standard has rather more to say about names than that:
A character string encoded using a 5 component convention. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between values in multiple valued data elements. The string may be padded with trailing spaces. For human use, the five components in their order of occurrence are: family name complex, given name complex, middle name, name prefix, name suffix.
Any of the five components may be an empty string. The component delimiter shall be the caret "^" character (5EH). Delimiters are required for interior null components. Trailing null components and their delimiters may be omitted. Multiple entries are permitted in each component and are encoded as natural text strings, in the format preferred by the named person.
For veterinary use, the first two of the five components in their order of occurrence are: responsible party family name or responsible organization name, patient name. The remaining components are not used and shall not be present.
This group of five components is referred to as a Person Name component group.
For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 groups of components (see Annexes H, I and J) may be used. The delimiter for component groups shall be the equals character "=" (3DH). The three component groups of components in their order of occurrence are: an alphabetic representation, an ideographic representation, and a phonetic representation.
Any component group may be absent, including the first component group. In this case, the person name may start with one or more "=" delimiters. Delimiters are required for interior null component groups. Trailing null component groups and their delimiters may be omitted.
Precise semantics are defined for each component group. See Section 6.2.1.2.
Ah! So, are you saying that it's actually not "yep, all the data fit", but "that which doesn't fit will be made to, by force if necessary"? Yup, that's what I am saying: let's just design this in a lazy way and pretend.
Can you propose a schema that permits all names to be represented without requiring coercion in any case? You'll need to start with with a graphical format, or a character encoding scheme more expressive than Unicode.
Computer system or not, you won't be admitted to a hospital with your name recorded as the first 1000 digits of pi followed by the emoji for coffee and a drawing of a mouse in sneakers.
I understand that the list is not a set of absolute rules, rather a set of caveats - even mutually exclusive ones! - and that an actual implementation will necessarily violate some of that, and that some intermediate representation would be needed. In other words, there will probably be a "name(s)" textfield, none of this graphical strawman.
What I have bristled at was the abovementioned "let's wish it away, that's enough: we'll pretend that everything is ASCII and let the users cope with our design problems ad hoc."
It depends which healthcare system you're dealing with. Legacy systems often have severe limitations. The more modern HL7 CDA R2 data interchange standard has an extremely flexible model for names which can properly accommodate the majority of "falsehoods".
Sometimes refusing to ship means that you just lost first to market advantage to someone who did. There are always trade offs, cost benefit analysis, and risk analysis to do with these decisions. For most software out there, assuming that a person at least has a name is a pretty safe assumption.
This is true in more places than software. Heck, even signing a check involves rendering a name in ink on paper, which is a restriction for some names I imagine.
Sure its true people have different renderings for their name. So choose one that fits into the software form you're filling out. Not rocket science.
My name is too long to fit on the Australian customs forms when I return from holiday. I just omit my middle names. I've yet to be refused entry.
Is there any requirement that one's signature be a handwritten version of the printed version of one's name?
My signature is pretty legible at least if you already see my name in print, but I know lots of people who sign a squiggle. Your name could be ʤᔙ but you still might sign it ᠼ and I doubt anybody would care.
(Made-up examples here, obviously.)
In some cultures a signature is somewhat like a signat-ring, a written emblem not necessarily related to alphabetic sequences. An 'X' for instance, signed on a contract by an illiterate and countersigned by a witness (well that was alphabetic but you get the idea). I knew a fellow from Bangalore who's signature was a graphic, some symbol written above a line and some letters below the line.
I'm told the squiggle is actually better than a legible signature. The legible signature is something you were trained to do following rules, and thus can be forged by someone else following the same rules. The squiggle is you, and so the existence/absence of some loop is enough to show a forgery and thus a forger has to memorize the entire thing with no rules to help.
I'm not qualified to state if the above is true, but I like to believe it is.
Also, if you have an elaborate squiggle, and you write it fast, it makes it very difficult to copy since the forger needs to write it quickly as well to get the same pen stroke results.
In Japan some places require me to sign my name with the exact same way than it's written in my passport using block letters. Normally I'd just write a cursive, stylized version (without my middle name).
Some other names allow stylized signatures, but then they require that the signature must be almost exactly the same every time I write it. Again, not something I'm used to.
This, of course reflects the fact that the Japanese don't use signatures to sign contracts. They use personal name stamps. The requirements make sense if you think your signature as a "name stamp that's written manually".
Of course, signatures are not names, they have extra cultural, societal and legal baggage, but... just a data point that might be interesting.
There was a minor kerfuffle a few years ago because Obama was considering someone for Secretary of Treasury whose signature (which would have appeared on all American bills) was just five or six loops. It bore no resemblance to his name. He just apparently decided that was going to be his signature, and that's what he used for most of this adult life.
I have really terrible handwriting, whenever I sign a document it literally is just some random continuous line. It's never been an issue. Nobody seems to care. You could probably make a smiley face and never have an issue regardless of the importance of the document.
Which is "it compiles? Ship it!" in a different cloak. And like the original, it will probably come to bite you.
Often the schema is already enforced - e.g. in healthcare you'll find that somebody else has already normalized the wonderful world of names down to two Unicode strings called last and first. Names that don't fit that schema will be coerced by this wonderful technology called "an admissions clerk".
The DICOM standard has rather more to say about names than that:
A character string encoded using a 5 component convention. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between values in multiple valued data elements. The string may be padded with trailing spaces. For human use, the five components in their order of occurrence are: family name complex, given name complex, middle name, name prefix, name suffix.
Any of the five components may be an empty string. The component delimiter shall be the caret "^" character (5EH). Delimiters are required for interior null components. Trailing null components and their delimiters may be omitted. Multiple entries are permitted in each component and are encoded as natural text strings, in the format preferred by the named person.
For veterinary use, the first two of the five components in their order of occurrence are: responsible party family name or responsible organization name, patient name. The remaining components are not used and shall not be present.
This group of five components is referred to as a Person Name component group.
For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 groups of components (see Annexes H, I and J) may be used. The delimiter for component groups shall be the equals character "=" (3DH). The three component groups of components in their order of occurrence are: an alphabetic representation, an ideographic representation, and a phonetic representation.
Any component group may be absent, including the first component group. In this case, the person name may start with one or more "=" delimiters. Delimiters are required for interior null component groups. Trailing null component groups and their delimiters may be omitted.
Precise semantics are defined for each component group. See Section 6.2.1.2.
For examples and notes, see Section 6.2.1.1.
Ah! So, are you saying that it's actually not "yep, all the data fit", but "that which doesn't fit will be made to, by force if necessary"? Yup, that's what I am saying: let's just design this in a lazy way and pretend.
Can you propose a schema that permits all names to be represented without requiring coercion in any case? You'll need to start with with a graphical format, or a character encoding scheme more expressive than Unicode.
Computer system or not, you won't be admitted to a hospital with your name recorded as the first 1000 digits of pi followed by the emoji for coffee and a drawing of a mouse in sneakers.
I can not, nor am I pretending to. What I was reacting to was this:
> Sometimes the answer to item 29:
> > And will your software only be dealing with people named by your society?
> Is: "yep"
https://news.ycombinator.com/item?id=18568710
I understand that the list is not a set of absolute rules, rather a set of caveats - even mutually exclusive ones! - and that an actual implementation will necessarily violate some of that, and that some intermediate representation would be needed. In other words, there will probably be a "name(s)" textfield, none of this graphical strawman.
What I have bristled at was the abovementioned "let's wish it away, that's enough: we'll pretend that everything is ASCII and let the users cope with our design problems ad hoc."
He's not wishing it away. His answer could just have been rooted in, "I understand my software won't cater to anyone. I'm ok with that."
Bristle at that if you must, I guess; some people aren't happy unless they're mad.
It depends which healthcare system you're dealing with. Legacy systems often have severe limitations. The more modern HL7 CDA R2 data interchange standard has an extremely flexible model for names which can properly accommodate the majority of "falsehoods".
Sometimes refusing to ship means that you just lost first to market advantage to someone who did. There are always trade offs, cost benefit analysis, and risk analysis to do with these decisions. For most software out there, assuming that a person at least has a name is a pretty safe assumption.