Skip to content
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

Merged
merged 4 commits into from
Aug 30, 2018

Conversation

kstreeter
Copy link
Collaborator

This PR is to address #469. Add fields to address each case for knowledge of a person's birth date:

  • the full date
  • the day and month only (no year)
  • the year only

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.

@kstreeter
Copy link
Collaborator Author

@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.

Copy link
Collaborator

@fmeschbe fmeschbe left a 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,
Copy link
Collaborator

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 ?

Copy link
Collaborator Author

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.

@kstreeter
Copy link
Collaborator Author

@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.

@kstreeter
Copy link
Collaborator Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants