Returned `dmrVersion` should reflect current version (v2) rather than version from potentially-stale DMR++

[Mikejmnez]

The dmrVersion = 1 | 2 attribute element within the dap response tells client APIs whether the data in the dap response is serialized according to the dap4 spec (dmrVersion=2) or if the data is serialized with Group data being serialized first (dmrVersion=1). The latest versions of the bes serializes data according to dmrVersion=2. See for example: http://test.opendap.org/opendap/dap4/SimpleGroup.nc4.h5.dmr.xml, which corresponds to Hyrax (1.17.1-691)

There is an issue, however, for Hyrax in the Cloud when there is a dmrpp that is "old". For example, this TEMPO example:

https://opendap.earthdata.nasa.gov/collections/C2930764281-LARC_CLOUD/granules/TEMPO_O3TOT_L3_V03_20250831T232841Z_S016.nc.dmr

The server has the version Hyrax (1.17.1-679). I ran that Hyrax version locally for a file with groups and the dmr has the attribute dmrVersion=2 meaning it fully supports it.

The issue is that, as in the TEMPO example above, the dmrVersion=1 in the dap response, BUT the data is serialized according to dmrVersion=2. As a result, data inside groups is deserialized incorrectly. IF I manually ignore this attribute in the dap response, and deserialize the dap response according to dmrVersion=2, the resulting data is correct.

@ndp-opendap mentioned there must be a caching issue, with the older dmrpp "next to the file". I looked at the DMRpp and indeed it has the dmrVersion=1 attribute, even though that version of Hyrax imposes the dmrVersion=2 serialization of the data.

<Dataset dapVersion="4.0" 
    dmrVersion="1.0" 
    name="TEMPO_O3TOT_L3_V03_20250831T232841Z_S016.nc" 
    ...
    dmrpp:trust="true" dmrpp:version="3.21.1-367>

Note that dmrpp version, corresponding to an "older" bes/hyrax (currently bes-3.21.1-1060).

[ndp-opendap]

Proposal:
Since the is only affects the order of serialization we might consider having the dmr++ parser (the dmrpp::DMZ class) simply change the value of dmrVersion from 1 to 2 when it parses the dmr++ document into DMRpp (DMR) object.

Because we know the serialization order is going to be the new way, always.

[hannahilea]

I've filed this as ticket #HYRAX-2026 in ngap's jira.

[ndp-opendap]

I looked at this in both libdap4 and BES.

The only place in the BES code where we use the method libdap::DMR::set_dmr_version() is in
DMZ.cc lines 309-311

        else if (is_eq(attr.name(), "dmrVersion")) {
            dmr->set_dmr_version(attr.value());
        }

In libdap4::DMR the default value is set to 2.0 with the declaration of the internal variable d_dmr_version:

    std::string d_dmr_version = "2.0";

But the code still implements sDMR::set_dmr_version() which, in libdap4, is only ever used in a single place in libdap::D4ParserSax2 on line 652:

        if (parser->check_attribute("dmrVersion"))
            parser->dmr()->set_dmr_version(parser->xml_attrs["dmrVersion"].value);

I now think the thing to do is this:

• Remove the libdap::DMR::set_dmr_version() method. (I know I know api/binary compatibility fail)
• Leave the existing libdap::DMR::dmr_version() which will, for now ,always return "2.0"
• Remove the two usages of libdap::DMR::set_dmr_version() , one from libdap4 and one from BES

If the thought of removing a method from the libdap API makes you crazy I suppose we could just stop using it in the BES and in libdap4 and that would have the same effect until somebody decides to use it in a new place.

Really though, if the dmrVersion is a function of the compiled code running on the server, and not a function a specific DMR(++) document's content/format then I can't see how having a setter for that value is a good plan.

[jgallagher59701]

One thing I wanted to talk to you all about is that while we named this attribute 'dmrVersion' we are actually using it to indicate 'the DAP serialization scheme.' They semantics are fuzzy. A counter argument to my first sentence is that this is actually indicating a bug fix.

[ndp-opendap]

The semantics are very fuzzy:

dmrVersion seems like it should be about the structure/content of a DMR document.

Might something to the tune of serialization="dap4" have been a better choice?

[Mikejmnez]

I also agree the semantics are fuzzy and I am all up for including better semantics.

[ndp-opendap]

A counter argument to my first sentence is that this is actually indicating a bug fix.

It is a bug fix, inside the server. It is not a change in the content/structure of the DMR, so I think using dmrVersion make sthat super confusing.

[jgallagher59701]

Yup, but it's what we've done. At least to this point. We could work on making it better, with the usual caveat about 'better.'

[ndp-opendap]

This dmrVersion thing is an intractable mess.

Let's do the following:

• Abandon this horrible dmrVersion attribute in favor of dap:serialization
• Make sure that when we write a dmr++ we DO NOT include the dap:serialization attribute in the document as that entirely a function of there service that is reading the dmr++ and then serving the data.
• Make sure that at runtime the BES code (the DmrppRequestHandler??) interrogates/uses the underlying libdap4 lib and/or have libdap itself add the correct value of dap:serialization attribute to every DMR/DAP response produced but the server.
• Again, the dap:serialization should MUST NOT be written into a dmr++ file. Just. Say. No.