Currently osm-adiff-parser has no input validation (apart from what's present in saxjs, which will throw an error if the input is not valid XML). This means that programs which use osm-adiff-parser (like osmcha-cli) might have surprising behavior if the user accidentally tries to use them to open an XML file that is not actually an Augmented Diff. For example, running the command below causes the browser to open and display a blank map, when it would probably be better to print an error message to stdout and exit.
# oops, this fetches a plain OSM XML document, not an Augmented Diff
curl -s 'https://api.openstreetmap.org/api/0.6/way/675905910' | osmcha
I'm not sure what the right level of validation is. Historically augmented diffs have used an <osm> root element which is the same as what is used by plain OSM XML data (cf. .osc files which use <osmChange> as the root element). So one option is to use (simple) heuristics to make sure that the input is an augmented diff and not a plain OSM XML file. For example, we could throw an error if the root <osm> element contains any <node>, <way>, or <relation> elements as direct children.
There's also some ongoing discussion about moving away from using <osm> for augmented diffs, and instead using a unique root element name. This could simplify validation for such augmented diffs, but osm-adiff-parser should also continue to accept (and ideally validate) augmented diffs that use <osm> at the top level, in the spirit of Postel's Law.
Currently osm-adiff-parser has no input validation (apart from what's present in saxjs, which will throw an error if the input is not valid XML). This means that programs which use osm-adiff-parser (like osmcha-cli) might have surprising behavior if the user accidentally tries to use them to open an XML file that is not actually an Augmented Diff. For example, running the command below causes the browser to open and display a blank map, when it would probably be better to print an error message to stdout and exit.
I'm not sure what the right level of validation is. Historically augmented diffs have used an
<osm>root element which is the same as what is used by plain OSM XML data (cf..oscfiles which use<osmChange>as the root element). So one option is to use (simple) heuristics to make sure that the input is an augmented diff and not a plain OSM XML file. For example, we could throw an error if the root<osm>element contains any<node>,<way>, or<relation>elements as direct children.There's also some ongoing discussion about moving away from using
<osm>for augmented diffs, and instead using a unique root element name. This could simplify validation for such augmented diffs, but osm-adiff-parser should also continue to accept (and ideally validate) augmented diffs that use<osm>at the top level, in the spirit of Postel's Law.