-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
Organisation of data #8
Comments
The primary sources are Apache, IANA, and user contributions. I do not think that it makes sense to separate these in terms of the data organization here—given the primary data use, as there is generally enough information to post-process the data into separate groups as needed. However, the IANA generally doesn’t include extensions, so if they are needed, they will (almost) always be user-contributed. |
Thanks for the quick reply. I was surprised that IANA don't list extensions. I sort of understand why, but it also seems like it would be really useful. |
You might be able to get it from individual RFCs that most IANA things are based on, but…obtaining that information would mean parsing the text of the RFCs. :/ |
Yeah, that's crazy talk :p |
There are potentially some things that can be obtained from individual records in the parsing.
It’s not structured, but it may be possible for some types. However, |
Have you considered proposing to IANA that they maintain a list of canonical file extensions? |
I haven’t; it’s probably not a bad idea, but I’m not sure how I’d start that particular discussion. |
I looked, they do capture file extension on their submission form, so perhaps they are thinking about it, or perhaps they do publish it, but not on that page? I've emailed them. |
|
They still haven’t added an extensions column yet. |
Some mime types come from IANA, right?
Is there some way to have separate data sources based on different orgs, e.g. IANA, Apache, Unofficial, etc.
Does that even make sense?
The text was updated successfully, but these errors were encountered: