6 ms·

I personally don't disagree, we've always thought it best to leverage other peoples work first. Though one of the largest discussions we had on the specificati

I personally don't disagree, we've always thought it best to leverage other peoples work first. Though one of the largest discussions we had on the specification was the definition of what a name was -> https://github.com/jsonresume/resume-schema/issues/4 https://github.com/jsonresume/resume-schema/issues/4 After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. When we looked at schema.orgs definition of Person, they went down the avenue of trying to split the name up which still wouldn't fit all use cases. https://schema.org/Person https://schema.org/Person

Jean-Philipe 7y ago
> After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. Thank you so much for this! Me and family members struggle filling forms because of this on a regular basis. Another pet peeve of mine are address fields. Why not just one field? People are smart enough to write down their address. Not everyone has a zip code or a street number, or streets for that matter.
- stronglikedan 7y ago
  > Why not just one field? Sales tax calculations by region.
- nulbyte 7y ago
  > People are smart enough to write down their address. Not usually. In this scenario, given its use for display on a user page, it may make sense. For most other cases, this doesn't pan out. Here in the US, for example, the general public has little sense of how to properly write addresses with floor, apartment, unit, or suite numbers. Folks routinely put things in the wrong order or use the wrong symbol or abbreviation. Others make up nonsense and genuinely think what they have is correct. Developers and geeks aren't immune; I've seen forms that reflect an inadequate understanding of addresses.
  - icxa 7y ago
    Yeah, if you work for a company that has to run any kind of validation on addresses, you learn quickly most people cannot type their address in correctly at all. My take: Make it as dumb and straightforwardly painfully obvious as possible.
    - abraae 7y ago
      Coincidentally enough, we just got through writing a nest of regexps to retrospectively validate about 2K user entered addresses, and they turned out to be surprisingly well entered, probably about 98% parsable. In this case the user was entering a field called "street" and we were validating down to a number followed by a street type (e.g ST) and a few local wrinkles such as additions like "RD1" for rural addresses. The most common error, which we brute force corrected, were various misspellings of "crescent". We did not however attempt to unpack the street number, which fortunately was not required.
goblin89 7y ago
Actually, Person does inherit a generic “name” property from its parent (Thing). You could support a subset of the spec (“name” but not “firstName”). It’d be very cool if I could have a single structured data representation that could be displayed in a neat resume format while being consumable by others (say, Google[0]). PS. Agreed on your name handling philosophy, I use a single “name” property wherever requirements allow. [0] https://developers.google.com/search/docs/guides/intro-structured-data https://developers.google.com/search/docs/guides/intro-struc...
wongarsu 7y ago
I've always gone with title, first name, middle name(s), last name, suffix; all optional (or requiring that at least one of first and last name exists), all representable in Unicode, space allowed but no line breaks, each part no longer than 300 characters. In theory that might not cover everything, but I've never been able to come up with a counter example. Schema.org seems to take a very similar approach. Of course assembling that back together is culture dependant and depends on your use case. If you only need a simple name field that's easier.
- bvda 7y ago
  Is there any reason not to use a singular field for this? It seems so much simpler to just give the user one input field and it would cover all scenarios.
  - wongarsu 7y ago
    Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently. Even in English the detail view might show George Walker Bush Jr (the legal name as the person might input it), while in the list you have to safe space and revert to George W. Bush. Greeting the person as "Hello George Walker Bush Jr" is silly, you want to say "Hello George" or "Hello Mr. Bush", depending on how formal you want to be. In languages such as Japanese you might end up generating honorifics on the fly. You can't do that if you can't parse the name.
    - bvda 7y ago
      Ah interesting, I hadn't thought of those use cases.
      - mbadros 7y ago
        I recall getting a chuckle out of the honorifics drop-down menu on the Rolls-Royce contact form. https://www.rolls-roycemotorcars.com/en-GB/information/contact-rolls-royce.html https://www.rolls-roycemotorcars.com/en-GB/information/conta...
einrealist 7y ago
You don't have to use the schema of schema.org. You can provide your own semantics (and build on pre-existing ones, like schema.org). The point is that you can provide information that is human readable and machine-processable (either through HTML or formats like JSON-LD).
C1sc0cat 7y ago
I seem to recall X.400/X.500 did a lot of work on how to represent names. Maybe if you could find a copy of those specs pity that the ISO and ITU where always so restrictive and dam expensive.

Jean-Philipe 7y ago

> After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. Thank you so much for this! Me and family members struggle filling forms because of this on a regular basis. Another pet peeve of mine are address fields. Why not just one field? People are smart enough to write down their address. Not everyone has a zip code or a street number, or streets for that matter.

stronglikedan 7y ago
> Why not just one field? Sales tax calculations by region.
nulbyte 7y ago
> People are smart enough to write down their address. Not usually. In this scenario, given its use for display on a user page, it may make sense. For most other cases, this doesn't pan out. Here in the US, for example, the general public has little sense of how to properly write addresses with floor, apartment, unit, or suite numbers. Folks routinely put things in the wrong order or use the wrong symbol or abbreviation. Others make up nonsense and genuinely think what they have is correct. Developers and geeks aren't immune; I've seen forms that reflect an inadequate understanding of addresses.
- icxa 7y ago
  Yeah, if you work for a company that has to run any kind of validation on addresses, you learn quickly most people cannot type their address in correctly at all. My take: Make it as dumb and straightforwardly painfully obvious as possible.
  - abraae 7y ago
    Coincidentally enough, we just got through writing a nest of regexps to retrospectively validate about 2K user entered addresses, and they turned out to be surprisingly well entered, probably about 98% parsable. In this case the user was entering a field called "street" and we were validating down to a number followed by a street type (e.g ST) and a few local wrinkles such as additions like "RD1" for rural addresses. The most common error, which we brute force corrected, were various misspellings of "crescent". We did not however attempt to unpack the street number, which fortunately was not required.

goblin89 7y ago

Actually, Person does inherit a generic “name” property from its parent (Thing). You could support a subset of the spec (“name” but not “firstName”). It’d be very cool if I could have a single structured data representation that could be displayed in a neat resume format while being consumable by others (say, Google[0]). PS. Agreed on your name handling philosophy, I use a single “name” property wherever requirements allow. [0] https://developers.google.com/search/docs/guides/intro-structured-data https://developers.google.com/search/docs/guides/intro-struc...

wongarsu 7y ago

I've always gone with title, first name, middle name(s), last name, suffix; all optional (or requiring that at least one of first and last name exists), all representable in Unicode, space allowed but no line breaks, each part no longer than 300 characters. In theory that might not cover everything, but I've never been able to come up with a counter example. Schema.org seems to take a very similar approach. Of course assembling that back together is culture dependant and depends on your use case. If you only need a simple name field that's easier.

bvda 7y ago
Is there any reason not to use a singular field for this? It seems so much simpler to just give the user one input field and it would cover all scenarios.
- wongarsu 7y ago
  Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently. Even in English the detail view might show George Walker Bush Jr (the legal name as the person might input it), while in the list you have to safe space and revert to George W. Bush. Greeting the person as "Hello George Walker Bush Jr" is silly, you want to say "Hello George" or "Hello Mr. Bush", depending on how formal you want to be. In languages such as Japanese you might end up generating honorifics on the fly. You can't do that if you can't parse the name.
  - bvda 7y ago
    Ah interesting, I hadn't thought of those use cases.
    - mbadros 7y ago
      I recall getting a chuckle out of the honorifics drop-down menu on the Rolls-Royce contact form. https://www.rolls-roycemotorcars.com/en-GB/information/contact-rolls-royce.html https://www.rolls-roycemotorcars.com/en-GB/information/conta...

einrealist 7y ago

You don't have to use the schema of schema.org. You can provide your own semantics (and build on pre-existing ones, like schema.org). The point is that you can provide information that is human readable and machine-processable (either through HTML or formats like JSON-LD).

C1sc0cat 7y ago

I seem to recall X.400/X.500 did a lot of work on how to represent names. Maybe if you could find a copy of those specs pity that the ISO and ITU where always so restrictive and dam expensive.