RESOStandards / transport

RESO Transport Workgroup - Specifications and Change Proposals
https://transport.reso.org
Other
18 stars 15 forks source link

[RCP-45] Legacy and Deprecated Data Elements #97

Open darnjo opened 11 months ago

darnjo commented 11 months ago

Discussed in https://github.com/RESOStandards/transport/discussions/36

Originally posted by **paulhethmon** August 1, 2022 Back in Confluence last month I asked: I’m looking for a way to handle and express lookups that are no longer in use but exist in older listing data. As an example the field **BusinessType** might have a lookup of **Video Store**. 20 years ago that was important and used, today, not so much. I would like to expose the Video Store lookup in my metadata as a searchable item (albeit legacy) but I can’t allow it to be used on a new listing. My search-fu this morning didn’t give me any leads on this, but it certainly seems like a situation many implementations would have. Is there something in the standard I missed? Do we need to fill the gap?

Assigned To: @paulhethmon

alifemove commented 11 months ago

Slightly related I think, I'd be interested to know if we can specify somehow whether a field is filterable or not.

darnjo commented 11 months ago

Good question, @alifemove. We have added a field for this called SearchableYN in the new Field Resource proposal (RCP-042). See: #76

alifemove commented 11 months ago

Bringing this from the discussion

DeprecatedDate. A date value of when a field became deprecated

I'm in favor of this, but I'd like to change the definition to A date value of when a field became or will become deprecated. We're already versioning between DD versions idk that we want to also version between our own schema versions and this feels like an easier way to communicate changes than a new schema version.

After that the only reason to have the mentioned FieldStatus would be for upcoming because everything else can be inferred (deprecated and date in the future? going away soon, deprecated and date in the past? already gone, not deprecated? its active), so maybe it's not needed at that point? I get wanting to inform consumers that a field will become available in the future, but if were doing that then it'd be nice to have another date to specify when it will become available, otherwise 'upcoming' is arbitrary and means different things for different companies/people. Upcoming next quarter? Next year? Next fiscal year? Next month? At that point feels like the dates are just becoming a LastModified field or something...