@stpeter That Q+A document does summarize the range of variation and the problem space inherent in personal names. Using a single, undivided field is an avoidance tactic. The other end of the spectrum, familiar to implementers of address book and contact applications, is a *much* more complex, nuanced data structure (which is usually coupled with locale-based presentation to hide unneeded complexity from e.g. your US English customers unless/except where they want it). Given+Family is a pretty common pattern that, while by no means universal, can be made sensible as an intermediate compromise between an opaque single-name-string and the full richness of human culturally linked naming. When it is the only structure for personal names, that usually leads to bad compromises for cultures that need more/fewer tokens for a name. If it is an adjunct to the opaque name string (`payerName`??) to allow a richer set of features, that might be okay. I would probably go at least one more step and allow for pronunciation fields (in Japanese, the "yomi") so that the resulting structure could be used for sorting a list of payers in Chinese/Japanese. But there is a slippery slope here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-request/issues/480#issuecomment-360293940
Received on Wednesday, 24 January 2018 22:23:13 UTC