michaelkamphausen
commented
3 years ago My gut says we should throw errors, but only if very basic information is missing that is absolutely not optional, so that further work with that file or dataset would result in errors or we would have to discard the dataset. For anything for which there are meaningful fallbacks, we should not throw.
westnordost
So far, only parsing of the filename. I'll get to parsing the EDIFACT next. I'll look at edifact parsers next whether any of those will make life easier here.
This draft PR should serve the purpose to just sync our code styles: does the code look like you would like it to be?
Specifically, I am not sure if the parser should be so "strict" (i.e. throw an Error if anything is not as expected) because Typescript/Javascript documentation seems to suggest to throw errors as little as possible. The alternative could be that each part that cannot be parsed would end up being
undefined, like "unknown".However, since we parse these files from a certain RSS feed, there is certainly the expectation that all files mentioned in that feed always correspond to this scheme and if they at one point not correspond to the expectation, that the whole parsing fails. Because "better safe than sorry".
Regarding the use of German names: I think the best approach is to first only use the German names as they are mentioned in the documentation as long as it is not clear if the term used is a specific term or not. Later, when the implementation is more complete, we can decide whether we can safely translate the term to English if for example the term is only used at one place in the documentation to describe a certain parameter. Example would the the "Verfahren" which doesn't even seem to be a fitting description in German! Better would be "Leistungserbringergruppe" or translated "health care provider group". "Einsatzgebiet" could be removed if there is really no other valid value, same with "FileFormat" etc.