-
Notifications
You must be signed in to change notification settings - Fork 29
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
contrib: dojson drop unknown fields #51
Comments
@greut I don't think we should remove unknown fields, actually this means that the translation for your data model is incomplete, therefore your tests should fail. I think the question here is whether or not the liberal MARC21 implementation should add to the output JSON all the unknown fields. IMHO it should. Just a side note, AFAIK the subfield |
Thanks @egabancho, lemme invoke the MARC lord @blixhavn. The silent removal looks like a way to be in trouble. |
Similarly to @egabancho I think the test should fail in this case (and not drop the field silently), because the input record is not compatible with the desired schema. There are basically two solutions: either (1) stick to standard MARC that does not seem to allow @aw-bib can advise about whether |
@tiborsimko how easy could be to amend/edit the schema for a particular purposes. E.g. the If you provide a liberal MARC, people will use this one because loosing data is bit of a no-go. |
The best example for 9xx so far is @egabancho's customisations for CERN-specific 9xx fields. I fully agree with you that loosing data is not acceptable, hence we should return an error, not silently ignore those "extra" fields. The error will hopefully prompt the site admins to amend the local schema rules to fit local cataloguing practices... or else switch to a liberal schema iike #26 that is very permissive on the input side. (At the price of loosing some precise JSON-Schema-generated editing forms.) Many sites have been calling for more permissive schema, see long discussion in #23, so perhaps we should get to implementing it sooner rather than later? |
* NEW Adds `ignore_missing` option to `Overdo.do` method to specify if method should raise when there is no matching rule for any key. (closes inveniosoftware#51) Signed-off-by: Jiri Kuncar <jiri.kuncar@cern.ch>
* NEW Adds `ignore_missing` option to `Overdo.do` method to specify if method should raise `MissingRule` exception when there is no matching rule for any key. (closes inveniosoftware#51) Signed-off-by: Jiri Kuncar <jiri.kuncar@cern.ch>
* NEW Adds new keyword argument `ignore_missing` to `Overdo.do` method to specify if method should raise `MissingRule` exception when there is no matching rule for any key. On can change the behavior of `do` command too by using `--strict` option that sets the `ignore_missing` argument to `False`. (closes inveniosoftware#51) Reviewed-by: Tibor Simko <tibor.simko@cern.ch> Signed-off-by: Jiri Kuncar <jiri.kuncar@cern.ch>
* NEW Adds new keyword argument `ignore_missing` to `Overdo.do` method to specify if method should raise `MissingRule` exception when there is no matching rule for a key. One can change the behavior of `do` command too by using `--strict` option that sets the `ignore_missing` argument to `False`. (closes inveniosoftware#51) Reviewed-by: Tibor Simko <tibor.simko@cern.ch> Signed-off-by: Jiri Kuncar <jiri.kuncar@cern.ch>
* NEW Adds new keyword argument `ignore_missing` to `Overdo.do` method to specify if method should raise `MissingRule` exception when there is no matching rule for a key. * NEW Adds new CLI option `--strict` to the `do` command that sets the `ignore_missing` argument to `False`. (closes inveniosoftware#51) Reviewed-by: Tibor Simko <tibor.simko@cern.ch> Signed-off-by: Jiri Kuncar <jiri.kuncar@cern.ch>
In #50, a test fails because a
subfield
is not part of the spec.the faulty record
the test
The spec says nothing about a
$9
subfield. But should it remove it nonetheless?The text was updated successfully, but these errors were encountered: