EML root element

[lkuiucsb]

I like to change my EML to the 2.2 version, so I use: emld::eml_version("eml-2.2.0") in my script.

Here is the output for the root element of the exported EML:

The xmlns:eml and xsi:schemaLocation elements do not match the ELM 2.2 documentation: https://github.com/NCEAS/eml.

I suggest change the xmlns:eml and xsi:schemaLocation to xmlns:eml="https://eml.ecoinformatics.org/eml-2.2.0" xsi:schemaLocation="https://eml.ecoinformatics.org/eml-2.2.0 https://nis.lternet.edu/schemas/EML/eml-2.2.0/xsd/eml.xsd"

[amoeba]

Hi @lkuiucsb, thanks for filing a new issue.

The behavior doesn't look like what I'm seeing. I'm thinking you might have old versions of emld, EML or both.

When I create a new EML record, my root element looks like:

<eml:eml 
  xmlns:eml="https://eml.ecoinformatics.org/eml-2.2.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:stmml="http://www.xml-cml.org/schema/stmml-1.2" 
  packageId="b5b560ba-adcf-40b7-a262-ef444f7703ff" 
  system="uuid" 
  xsi:schemaLocation="https://eml.ecoinformatics.org/eml-2.2.0/ eml.xsd">

which looks right. Can you check your versions? You can do that by running devtools::session_info() and looking at the output for:

EML         * 2.0.0      2019-04-23 [1] CRAN (R 3.6.0)                       
emld          0.3.0      2019-10-11 [1] CRAN (R 3.6.0)  

[lkuiucsb]

OK, two things happening here. First, I update my emld pacage, here is the version check EML * 2.0.0 2019-09-26 [1] Github (ropensci/EML@925776a)
emld 0.3.0 2019-10-11 [1] CRAN (R 3.6.0)

Here is my output: <eml:eml xmlns:eml="https://eml.ecoinformatics.org/eml-2.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:stmml="http://www.xml-cml.org/schema/stmml-1.2" packageId="knb-lter-sbc.127.1" xsi:schemaLocation="eml://ecoinformatics.org/eml-2.1.1 http://nis.lternet.edu/schemas/EML/eml-2.1.1/eml.xsd" system="knb">

The xmlns:eml looks right now. But the schema location is not right(2.1.1 version).

In the case @amoeba posted, the schema location is at "eml.xsd". Not all the users store a local schema copy. Thus, the schema location should point to a web address such as ecoinformatics.org.

I am not sure why the EML root element is different between us. I don't see any function in the EML package can change the shcemaLocation.

[amoeba]

Thanks @lkuiucsb . The xmlns:eml is still not quite right, as I think the value should be a URI which it's not in your case. Are you reading an existing EML file from somewhere or creating one from scratch? If possible, could you share a minimal snippet or code that I can use to attempt to reproduce your issue?

Re: xsi:schemaLocation and its value, my understanding is that the XML schema spec doesn't require the schemaLocation to point anywhere in particular. It's more of a hint for clients doing validation. We point to a local copy of the XSD for our purposes and you're welcome to customize the value to your needs. However, if you can find anything in the spec that disagrees with that, please let us know.

[lkuiucsb]

Thanks @amoeba ! I just figure out that I have assigned the schema location in my eml generation code. So I think I am set for this. Sorry for the trouble!

Re: schemaLocation You are right that XML schema spec doesn't require the schemaLocation. It only matters if I want to validate the xml in an environment other than R (e.g. Oxygen). If I don't keep a local xsd copy but want to validate the R-output eml document in Oxygen, I have to change the location to lternet.edu schemas address or keep a local copy on my machine. If the default eml output from EML package specifies a non-local copy, isn't that convenient?

[mbjones]

Agreed that the schemaLocation is an optional hint. Now that we are serving the eml schemas from the default namespace, you could use:

xsi:schemaLocation="https://eml.ecoinformatics.org/eml-2.2.0 https://eml.ecoinformatics.org/eml-2.2.0/eml.xsd"

which would resolve to the main distribution site for EML. Its still a good idea to use local copies of the schema in your applications to avoid both network issues and XML injection attacks.

[amoeba]

No worries @lkuiucsb and I'm glad you got it sorted out. I can't close Issues here so, @lkuiucsb, if you're all set, could you please close this? Thanks!