I have been noticing that often time there are some intermittent errors during testing associated with the dmr parser, in particular when dealing with the dimensions at the variable level. The dmr parser is located in

I notice that during testing (no locally but only when run with github worflows) the are some scenarios in which the parser errs. Running it again usually solves the issue.

Furthermore, in xarray a test fails when comparing the dimensions in an array. For example I have seen:

xarray/tests/test_backends_datatree.py::TestPyDAPDatatreeIO::test_open_groups
  /home/runner/work/xarray/xarray/xarray/namedarray/core.py:261: UserWarning: Duplicate dimension names present: dimensions {'lon'} appear more than once in dims=('lon', 'lon'). We do not yet support duplicate dimension names, but we do allow initial construction of the object. We recommend you rename the dims immediately to become distinct, as most xarray functionality is likely to fail silently if you do not. To rename the dimensions you will need to set the ``.dims`` attribute of each variable, ``e.g. var.dims=('x0', 'x1')``.
    self._dims = self._parse_dimensions(dims)

FAILED xarray/tests/test_backends_datatree.py::TestPyDAPDatatreeIO::test_open_groups - AssertionError: Left and right Dataset objects are not identical
Differing dimensions:
    (lat: 1, lon: 2) != (lon: 2)
Differing data variables:
L   group_1_var  (lat, lon) float64 16B ...
R   group_1_var  (lon, lon) float64 32B ...

and

Differing data variables:
L   group_1_var  (lon, lat) float64 16B ...
R   group_1_var  (lat, lon) float64 16B ...

NOTE the dimensions...
I am not 100% sure these two are related (pydap only issues and xarray+pydap issues), but they might be.

What makes this difficult to diagnose, is that this error never shows up on my local testing...

Lastly, this is all in addition to the dap responses are deserialized, which is intrinsically related to the order in which the dmr parsers elements in the xml.

This is in addition to #551

So because order of serialization in pydap is intrinsically related to order in which each object is created while parsing a dmr, this issue/bug will be fixed when pydap creates each object in the way it which it will be serialized (i.e. according to the way each object is represented in the dmr).

Originally posted by @Mikejmnez in #551