Passing arguments to `write_xml`

[peterdesmet]

The documentation for EML::write_eml states that ... allows to pass arguments to xml2::write_xml(). Is that the case though? In write_eml(), ... is not passed further to:

EML/R/write_eml.R

Line 33 in b7871cc

emld::as_xml(eml, file, ns = ns)

... and emld::as_xml() doesn't accept ...

[mbjones]

I agree the arguments are not being passed through. I think this was changed when we switched to emld as the backend that writes out the XML, rather than doing it directly in this package, and we forgot to update the docs. emld uses xml2::write_xml under the hood (see https://github.com/ropensci/emld/blob/master/R/as_xml.R#L93) and doesn't provide a mechanism for further arguments to be passed. So changes would be needed there too.

What are you trying to use this for? Are there serialization options you need?

I propose we should just remove the ... from the docs and call it good unless there is a specific need/use case.

[peterdesmet]

What are you trying to use this for? Are there serialization options you need?

I'm trying to solve inbo/camtrapdp#180 in order create EML extended with properties for GBIF.org. I just found the culprit is jsonlite::toJSON() called by emld:::eml_frame(). If you think my use case is valid, I can log an issue at https://github.com/ropensci/emld/issues

But I don't think it will be resolved by passing options to ... so I'm fine with removing those from the docs.

[cboettig]

@peterdesmet apologies for these problems and thanks for the detailed issue reports.

I think it's worth opening an issue in emld, maybe we can simply intercept or post-process to the toJSON output to squash the .1 suffixes etc.

More of an editorial note here, but I'm afraid there will always be edge cases the R packages don't cover, for which users should rely on the existing XML R bindings like xml2 can be used to do anything you would need to do in XML (either to write the EML from scratch or simply patch or extend EML generated by this or emld packages.

emld is a opinionated hack that essentially tries to treat EML as if it were really JSON rather than XML. This is obviously a false assumption (leaky abstraction?) as the data models are vastly different and JSON just can't handle everything we can do in XML. But from the perspective of a developer or end user, I think that's a feature of emld. In R and many other popular languages, the JSON / list / dictionary model is much easier to work with and reason about, and even maps pretty naturally into RDF semantics (json-ld) that we also exploit in emld. Crucially, this means that both users and other developers ought to be able to generally rely on natural R data structures (or equivalents in python, javascript, etc) to express many common EML classes. This sets up an inevitable trade-off between being able to work 'easily' with EML as native R and not thinking in XML, vs having access to the full XML abilities and expressiveness.

Right, we should update the docs on ....