-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 469 - Create distinct fields for different cases of birth date #498
Conversation
@lrosenthol, @fmeschbe take a look at this and let me know if you have any comments. I spoke with Aaron (who filed #469) this approach seems to address the issues raised. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR suggests replacing three fields for day, month, year with another three fields simulating partial dates for which the ISO 8601 spec already has a solution.
I am not really sure, this is a good way to move forward.
In addition, we are primarily defining exchange formats, right ? So we should concentrate on this exchange and how this could be easily used by multiple parties in the interaction and less about how we would really implement it ?
Actually, even the proposed PR leaves quite some open questions on how this would be implemented in a meaningful way: How is month-day date internally represented ?
"title": "Birth year", | ||
"type": "integer", | ||
"description": "The year a person was born including the century (yyyy, e.g 1983). This field should be used when only the person's age is known, not the full birth date.", | ||
"minimum": 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this minimum for a birth year reasonable ? I mean, if we set limits, shouldn't those limits be meaningful ?
In other words, is a birth year of, say, 67, reasonable for our XDM use cases ? And why would -100 (the assumed birth year of Julius Caesar) not be ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this needs work. This definition will let folks move forward, we should improve this under a new issue.
@fmeschbe, I don't think it is accurate to call XDM an "exchange format", although that is one use. XDM is also the metadata layer used to describe both the structure and semantics of data in our platform. Systems we have built read this metadata and make assumptions about how to interpret and display data. These systems frequently map from definitions made in XDM JSON Schema into the semantically equivalent form of their internal implementation. So we need to take care not to introduce semantics into JSON Schema that these systems can't understand. The new (and unpublished) semantics of partial dates in the latest ISO 8601 draft have not been translated into JSON Schema. There is no support for it in any of the tooling or programming environments we use. We need a solution that we can adopt now. |
Thank you all for the discussion on this issue, but as we have not gotten any viable counter-proposals we are going to go with this change for now so that teams can move forward. These schemas are no yet locked down, so if folks want to propose improvements they will definitely be considered! |
This PR is to address #469. Add fields to address each case for knowledge of a person's birth date:
The existing fields for "xdm:birthDay" and "xdm:birthMonth" will be deprecated.
Note this is intended to supercede PR #481. Since that PR is not on a branch in this repo I could not just update it directly.