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

📄🚀 Add factor labels #202

Open
e-lo opened this issue Jan 3, 2024 · 1 comment
Open

📄🚀 Add factor labels #202

e-lo opened this issue Jan 3, 2024 · 1 comment
Labels
🚀 feature Adds a new feature - to spec or code 📝 non-normative Non-normative changes can be approved by other contributors 📄 spec Pertains to the specification itself

Comments

@e-lo
Copy link
Contributor

e-lo commented Jan 3, 2024

Describe the feature you want and how it meets your needs or solves a problem

As a TIDES user, I want the labels of enumerated values to be documented in the spec so that their descriptions can be self-documenting.

Describe the solution you'd like

New support for this in Frictionless: frictionlessdata/datapackage#844

@e-lo e-lo added 🚀 feature Adds a new feature - to spec or code 📄 spec Pertains to the specification itself 📝 non-normative Non-normative changes can be approved by other contributors labels Jan 3, 2024
@botanize
Copy link
Contributor

botanize commented Feb 1, 2024

I'm pretty sure enums are enumerated by value in the spec, e.g.,

and https://tides-transit.org/main/tables/#vehicle-locations.

Are you asking for option 1 (adding "enumOrdered": true), or 2, using integers for the enum values and adding enumLabels? It doesn't look like either of those would make enums any more self-documenting.

Or is this specifically about referencing enums from other sources, like GTFS route types in trips_performed, where we'd need to use option 2 to align the integer values with the GTFS standard?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 feature Adds a new feature - to spec or code 📝 non-normative Non-normative changes can be approved by other contributors 📄 spec Pertains to the specification itself
Projects
None yet
Development

No branches or pull requests

2 participants