29 ms·

CSV is not a standard (rfc4180 exists but only very few things actually pay attention to it) so no behavior is a sane behavior when trying to import it.

stonogo 3y ago
You sound like a C compiler. "This is technically undefined behavior so whatever" is not a useful guiding principle for user interfaces.
- ElectricalUnion 3y ago
  A normal user interface would guide you away from using CSV in the first place. In almost all situations where one could use CSV, a better, more structured, more standards-compliant, more optimized file format (like a SQLite database) would be a better choice.
  - stonogo 3y ago
    In situations where people are opening a CSV file in an office-suite spreadsheet app, they probably didn't generate the data themselves. Lecturing them about how their spreadsheet should have been a database isn't likely to help, and describing SQLite's file format, which is well-documented but not a standard, as "more standards-compliant" than a file format with an actual RFC is bordering on ridiculous.
    - ElectricalUnion 3y ago
      The Library of Congress, an agency of the legislative branch of the U.S. government thinks that SQLite3 [1] is a acceptable database format. The Library of Congress has a small amount of SQLite files in its collections. The Library of Congress also cites CSV [2], Comma Separated Values, as strictly specified in RFC 4180 as a acceptable dataset format. No other types of free-form CSV that aren't variants compliant with 4180 are accepted, and it also says that documentation and metadata needs to be supplied with additional separated archives in supported data formats. The Library of Congress has 0 CSVs in its collections, and as a result no experience actually handling it. I believe that if a widespread format such as CSVs have 0 files added to a reasonably well known and encompassing collection of human artifacts related to culture even with its ubiquity, it's a telltale sign that it isn't a standard at all. [1] https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd0004... [2] https://www.loc.gov/preservation/digital/formats/fdd/fdd000323.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd0003...
      - stonogo 3y ago
        This is all completely irrelevant. No office suite user gives a shit what the Library of Congress thinks about database formats, because spreadsheets are not databases, no matter how often you personally conflate the two. Furthermore, the LoC's job is archiving. Your links have "preservation" in the url for a reason, and "preservation" is not what people do with spreadsheets. To strive for relevance, explore https://data.gov https://data.gov, where CSV is abundant, because it's in use by literally hundreds of state and federal agencies, often by people using spreadsheet software, and will continue to be so for years or decades to come, whether you understand why or not. edit: Your assertions are wrong anyway, as the LoC does indeed have CSV artifacts in its collection. It is most often in a Zip file and catalogued as "compressed data," which is probably why your perfunctory search did not unearth it. Some random counterexamples to your claim: https://www.loc.gov/item/2022482299/ https://www.loc.gov/item/2022482299/ https://www.loc.gov/item/2020446966/ https://www.loc.gov/item/2020446966/ https://www.loc.gov/item/2023590205/ https://www.loc.gov/item/2023590205/ https://www.loc.gov/item/2018655320/ https://www.loc.gov/item/2018655320/
        ElectricalUnion 3y ago
        > This is all completely irrelevant. No office suite user gives a shit what the Library of Congress thinks about database formats, because spreadsheets are not databases, no matter how often you personally conflate the two. I did not conflate database and dataset. I specifically described the two types. The Library of Congress specifically describes the two types. You decided that "others" think that database and dataset are conflated, and that they are wrong. > edit: Your assertions are wrong anyway (...) Some random counterexamples to your claim: It's not my assertion, it's a assertion by the Library of Congress itself. The Library declares that it has no experience directly handling CSV. > "LC experience or existing holdings": None in relation to collection holdings [1] > "LC experience or existing holdings": "Report of actual practice at the Library of Congress." [2] [1] CSV, Comma Separated Values (RFC 4180) - https://www.loc.gov/preservation/digital/formats/fdd/fdd000323.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd0003... [2] Format Descriptions: Explanation of Terms, Local Use - https://www.loc.gov/preservation/digital/formats/fdd/fdd_explanation.shtml#local https://www.loc.gov/preservation/digital/formats/fdd/fdd_exp...
tbeiwhsj 3y ago
[dead]

stonogo 3y ago

You sound like a C compiler. "This is technically undefined behavior so whatever" is not a useful guiding principle for user interfaces.

ElectricalUnion 3y ago
A normal user interface would guide you away from using CSV in the first place. In almost all situations where one could use CSV, a better, more structured, more standards-compliant, more optimized file format (like a SQLite database) would be a better choice.
- stonogo 3y ago
  In situations where people are opening a CSV file in an office-suite spreadsheet app, they probably didn't generate the data themselves. Lecturing them about how their spreadsheet should have been a database isn't likely to help, and describing SQLite's file format, which is well-documented but not a standard, as "more standards-compliant" than a file format with an actual RFC is bordering on ridiculous.
  - ElectricalUnion 3y ago
    The Library of Congress, an agency of the legislative branch of the U.S. government thinks that SQLite3 [1] is a acceptable database format. The Library of Congress has a small amount of SQLite files in its collections. The Library of Congress also cites CSV [2], Comma Separated Values, as strictly specified in RFC 4180 as a acceptable dataset format. No other types of free-form CSV that aren't variants compliant with 4180 are accepted, and it also says that documentation and metadata needs to be supplied with additional separated archives in supported data formats. The Library of Congress has 0 CSVs in its collections, and as a result no experience actually handling it. I believe that if a widespread format such as CSVs have 0 files added to a reasonably well known and encompassing collection of human artifacts related to culture even with its ubiquity, it's a telltale sign that it isn't a standard at all. [1] https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd0004... [2] https://www.loc.gov/preservation/digital/formats/fdd/fdd000323.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd0003...
    - stonogo 3y ago
      This is all completely irrelevant. No office suite user gives a shit what the Library of Congress thinks about database formats, because spreadsheets are not databases, no matter how often you personally conflate the two. Furthermore, the LoC's job is archiving. Your links have "preservation" in the url for a reason, and "preservation" is not what people do with spreadsheets. To strive for relevance, explore https://data.gov https://data.gov, where CSV is abundant, because it's in use by literally hundreds of state and federal agencies, often by people using spreadsheet software, and will continue to be so for years or decades to come, whether you understand why or not. edit: Your assertions are wrong anyway, as the LoC does indeed have CSV artifacts in its collection. It is most often in a Zip file and catalogued as "compressed data," which is probably why your perfunctory search did not unearth it. Some random counterexamples to your claim: https://www.loc.gov/item/2022482299/ https://www.loc.gov/item/2022482299/ https://www.loc.gov/item/2020446966/ https://www.loc.gov/item/2020446966/ https://www.loc.gov/item/2023590205/ https://www.loc.gov/item/2023590205/ https://www.loc.gov/item/2018655320/ https://www.loc.gov/item/2018655320/
      - ElectricalUnion 3y ago
        > This is all completely irrelevant. No office suite user gives a shit what the Library of Congress thinks about database formats, because spreadsheets are not databases, no matter how often you personally conflate the two. I did not conflate database and dataset. I specifically described the two types. The Library of Congress specifically describes the two types. You decided that "others" think that database and dataset are conflated, and that they are wrong. > edit: Your assertions are wrong anyway (...) Some random counterexamples to your claim: It's not my assertion, it's a assertion by the Library of Congress itself. The Library declares that it has no experience directly handling CSV. > "LC experience or existing holdings": None in relation to collection holdings [1] > "LC experience or existing holdings": "Report of actual practice at the Library of Congress." [2] [1] CSV, Comma Separated Values (RFC 4180) - https://www.loc.gov/preservation/digital/formats/fdd/fdd000323.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd0003... [2] Format Descriptions: Explanation of Terms, Local Use - https://www.loc.gov/preservation/digital/formats/fdd/fdd_explanation.shtml#local https://www.loc.gov/preservation/digital/formats/fdd/fdd_exp...

tbeiwhsj 3y ago

[dead]