Correct the handling of absolute path for DynaML.xsd: v1.3.0 import.exe can fail without error

[jhaasdyk-au]

Brief description
Where the absolute path to DynaML.xsd is supplied in (any of the) XML input file(s), failure to provide the xsd at that absolute path results in import.exe exiting without error message.

Background
RE: dynadjust-windows-mkl.zip; dynadjust-1.3.0-windows-openblas.zip

Recent changes were made to handling absolute vs relative path for DynaML.xsd (e.g. 12d977c)

Note: DynaML.xsd is ALSO required in the current directory, otherwise an error is reported Error: ParseXML(): DynaML.xsd schema file not found in the current directory. This test is performed even if an absolute path is supplied in all xml input files.

Basic requirements
Support DynaML.xsd in relative path (e.g. current directory)
Support DynaML.xsd in PATH (if not: why support current directory only, and not just in PATH?)
Support DynaML.xsd in absolute path; over-ride path(s) above (but only for the single file in question)

Consider (1): report path to DynaML.xsd at time of parsing.
Consider (2): is there any use-case to apply more than one xsd? or just the first encountered?
examples (report one or more of the following):
+ Parsing:
DynaML.xsd supplied at Input Folder (see above)
DynaML.xsd supplied at PATH C:\DynAdjust\exe
301955_stn.xml... Done. Loaded 7 stations in 0.028s DynaML.xsd supplied at absolute path
or
301955_stn.xml... Done. Loaded 7 stations in 0.028s Ignored DynaML.xsd at absolute path in file header

Priority
Priority 2 - medium

[daleroberts]

@jhaasdyk-au Does NSW edit the DynaML.xsd in any way, or do you just use the one provided by DynAdjust?

I'm wondering if there is a better way to do this, this file causes GA lots of headaches too.

[nicgowans]

G'day @daleroberts,

NSW practice is to adopt the DynaML.xsd as supplied here without alteration. The only variation we have is that we typically configure our XML stn/msr files to refer to a constant location, e.g.:
<DnaXmlFormat type="Station File" referenceframe="ITRF2014" epoch="23.02.2018" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\DynAdjust\exe\DynaML.xsd">

[daleroberts]

Looking through the code, it turns out that the DynaML.xsd is actually never used for XML validation, so I am going to suggest that we remove the requirement for this file completely.

@rogerfraser has pointed out that once the XML data is parsed there are a number of data validation checks that are done:

• There must be a positive number of directions
• You can't have blank Type
• Are the standard deviations valid

and so forth. I am not suggesting to remove these.

[rogerfraser]

For context, codesynthesis C++/Parser was used to generate C++ classes from DynaML.xsd that enable fast data loading from large DynAdjust xml files. As documented here, C++/Parser generates skeleton classes for all the data types found in the XSD schema (e.g. DnaStation, DnaMeasurement, First, Second, GPSBaseline, Vscale, etc.). The skeleton classes are contained in dnaparser_pskel.hxx and dnaparser_pskel.cxx. These skeletons have been extended with application logic to assert essential validation rules. The xml data parsing and validation rules are implemented in dnaparser_pimpl.hxx and dnaparser_pimpl.cxx.

As @daleroberts suggests, various checks are performed in dnaparser_pimpl.cxx to assert various rules to prevent bad data from being loaded. For example, to assert that the number of directions provided matches the value in <Total>...</Total>, validation is undertaken at xml data parsing here. To check that the supplied reference frame in <ReferenceFrame>...</ReferenceFrame> is valid, a check is undertaken (via SetReferenceFrame(...)) during data parsing here. Hence, in both cases, DynaML.xsd is not used to validate the XML data, rather, the C++ parsers in dnaparser_pimpl.cxx are.

This work will investigate how dependency on xsi:noNamespaceSchemaLocation="DynaML.xsd" in the xml files might be altered such that validation can occur without the need for the (relative or absolute) presence of DynaML.xsd.

[jhaasdyk-au]

I'm happy to adopt your recommendation here.

In any case, the user cannot modify or supply a different xsd without associated changes to the code, so it makes sense to house this information in the dnaparser(s) linked above.