-
Notifications
You must be signed in to change notification settings - Fork 1
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
More flexible dialect parsing #5
Comments
Thanks for reaching out. It's always interesting to hear what people are building with csvw! Having individual dialect values override the defaults seems like a reasonable behaviour. Indeed it looks like some of the csvw tests expect this anyway. We'll need a function to merge the lists, and - looking at your example - it ought to treat |
Thanks for your answer! Yes, the behaviour you describe would be ideal. Looking at Lines 224 to 228 in 3c65f95
it seems that only parts of the dialect spec are taken into account as of now. Is that correct? FWIW, I built a Python package for csvw (https://github.com/cldf/csvw/) and found completely supporting csv dialect specs surprisingly non-trivial ... |
Yes that's right. I've only implemented the bits I've encountered so far ( We've been gathering some resources on csvw.org. Would you like to have |
I'm not sure whether my csvw package should be included on csvw.org, considering its limitations and deviations. But then, I guess most of the tools have rough edges :) |
Yeah, no specification is comprehensive and it gets harder still when you start to combine/ extend them! It's no surprise all the implementations end-up slightly different. As long as it's explicit then I think that's totally fine. I'll add it to the tools page when I get a chance! |
3d05de8 introduces an You're example works now: > cldf <- read_csvw("https://raw.githubusercontent.com/glottolog/glottolog-cldf/c8eefe82b4c87f3c566a8e5181bacf714661e18e/cldf/cldf-metadata.json")
> cldf$dialect$commentPrefix
NULL Thanks for the report! |
Hi, I'm one of the creators of a data standard (CLDF) which is based on csvw. Unfortunately we decided to allow a
dialect
property specifying only the properties which deviate from the default dialect. E.g. here.This seems not to work with current
csvwr
:When I remove the
dialect
property from the metadata (falling back to the default) all is good:If dialect properties would be merged in
csvwr/R/csvwr.R
Line 217 in 3c65f95
rather than just choosing a fully specified custom dialect or the default,
csvwr
could handle our data out-of-the-box.Would you consider switching to such a dialect parsing behaviour an option for
csvwr
?The text was updated successfully, but these errors were encountered: