![]() ![]() The coherent use of CSV is more difficult for us… And there are a “history collective trauma” with CSV in the country’s culture. To fix the bug the information about decimal-separator must be “easy to get”: even when expressed in a TableSchema context, it is not obvious to CSV parser, neither easy to check by people that will explain how to open the CSV file. To lost a decimal-separator is a bug, and with it we lost reliability in all the open-data ecosystem. View/Import/Export CSV files are critical operations for serious use. In that countries we need to show confidence in our choice of an open-data ecosystem, all days. that represents ~50% of the countries using Arabic numerals with decimal comma. It is for Angola, Azerbaijan, Bolivia, Bosnia, Brazil… All countries with other reality and “low digital maturity”, with low national-standards enforcement, etc. It is not for USA, where we have no problem, even not for Europe, where we are in a high maturity context. ( sorry, to verbose, adding more context and drama ) To add the decimalChar parameter in the specs/csv-dialect specification. So, to this new issue, thanks for I can express more formally the suggestion: Where each dataset have a complete description in its metadata… A complex and so detailed datapackage.json…īut the context here is “only CSV”… We can imagine a dataset in a context of low maturity, were the only thing is the CSV file and a very simple JSON, with some or all 8 parameters as default. Well, it seems a solution when we using “CSV + TableSchema” specifications, as in So it is a piece in the solution of the problem, thanks! Hi and agree that decimalChar has exactly the semantic of the parameter that I was looking for, … Another option is to say “Please be consistent in your community”, saving and reading CSV files with the same locale (and no other “obvious” assumption about decimal-separator interpretation)… But it is a error-prone stance, as experience has shown: the parameter will well-come for reliability aims. Will be also an enhancement for digital preservation and data provenance. Is possible to add a decimal-separator parameter in the csv-dialect? This information must to stay with the CSV description (the JSON metadata with the CSV Dialect descriptor)… And I not see it at frictionlessData/specs/csv-dialect. There are good standards about “other necessary environment parameters”, as ISO15897 and CLDR, that really say “my decimal-separator is comma” when I need it as my locale.īut the problem is not the locale of the CSV-reader agent, that must render the layout as user whant, the problem is the origin of the dataset: “When I generated originalSpreadsheet.csv what locale I was using on the CSV-write agent?”. The CSV standard is adaptable, there are 9 environment parameters to define the file format (delimiter, doubleQuote, lineTerminator, quoteChar, etc.)… But there are no paramter to say “my decimal-separator is comma”. … In the horst cenario we lost all effort to use frictionlessData/specs, and community back to use XLS and XLSX as data-interchange standard (where the information about decimal separator isn’t lost). One year later somebody is reading the originalSpreadsheet.csv file with my country’s locale settings, with MS-Excel or Google-spreadsheet… The numeric column is reading as integer not as decimal. Make sense for me and for some others working and testing in the same environment, so we continue to do the same thing… ![]() (and numbers will stay as numbers not strings) Of course, if I am using comma as delimiter, the decimal-separator is point, not comma, because any CSV cell without quotes will be interpreted as a number. I published my dataset as originalSpreadsheet.csv, saving it as CSV with comma as delimiter - no special decision, only because it seems natural, the comma-separated tradition. Imagining… I have an originalSpreadsheet with my dataset. On my country we use comma as decimal separator, but we accept as human-readable, in data-interchange standards like JSON and CSV, the point as decimal separator. ![]() … or perhaps only an opportunity to say “hello I am in the CSV hell of the decimal-separator interpretation”. This is a question, perhaps a suggestion for Frictionlessdata specs/CSV dialect ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |