通过JSONIX解组SOS DescribeSensor响应会产生不完整的对象

Question

我正在尝试使用jsonix从SOS DescribeSensor请求解组xml响应。在更广泛的范围内，我将使用jsonix解组来自SOS的所有响应，尤其是2.0。我注意到响应使用了SML或SensorML命名空间，因此我添加了额外的模块依赖关系和子依赖关系（即GML_3_1_1，SWE_1_0_1，IC_2_0，SMIL_2_0，SMIL_2_0_Language，当然还有SensorML_1_0_1）。在我添加这些之前，我注意到返回是一个通用的json（参见第一个截图，特别是在sml：physicalsystem附近）。在我添加了依赖项之后，我在控制台中遇到了一个错误，在解组过程的一部分我不明白（参见第二个屏幕截图）。以下是来自服务器的xml响应的链接以供参考。 https://drive.google.com/file/d/0B8LdnPVJpHz7M3VGb0FZc2lQcjQ/view?usp=sharing。我真的很想知道，当我创建上下文时，这是否与模块的顺序有关，尽管我认为它很好。一旦找到解决方案，我就会有两个跟进问题。

1. 期望（通常）在highsource github页面上使用从ogc-schemas构建的模块应该允许我通过jsonix处理所有响应是否合理？即每个元素将始终映射到定义的类型。我知道这些模式/映射非常复杂。

2. 我是否可以使用其他任何工具来验证模块或针对模式验证它们以使生活更轻松，而不是单独跟踪元素或在jsonix似乎解析不正确时追踪各种模块文件？< / p>

提前致谢 - Richard3d

var context = new Jsonix.Context([XLink_1_0, GML_3_2_1, IC_2_0, SMIL_2_0, SMIL_2_0_Language, GML_3_1_1, SWE_1_0_1, SensorML_1_0_1, OWS_1_1_0, SWE_2_0, SWES_2_0, WSN_T_1, WS_Addr_1_0_Core, OM_2_0, ISO19139_GMD_20070417, ISO19139_GCO_20070417, ISO19139_GSS_20070417, ISO19139_GTS_20070417, ISO19139_GSR_20070417, Filter_2_0, SOS_2_0]);

Answer 1

免责声明：我是jsonix的作者和ogc-schemas的主要开发者。

首先，你走在正确的轨道上，坚持下去。

是的，如果你有所有必需的映射，那么你应该得到一个好的＆＃34;具有特定类型，忠诚度等所有属性的JSON Jsonix的目标是提供具有确定性结构，类型和基数的双向XML＆lt; - ＆gt; JSON转换。
OGC Schemas的目标是为所有OGC模式提供JAXB和Jsonix映射。
所以要注意这两个应该允许将任何OGC XML转换为JSON。

＆＃34; Generic JSON＆＃34;实际上只是DOM。如果属性允许DOM并且Jsonix没有某个元素的映射，那么它只是作为DOM。您刚刚缺少SensorML映射。

你对架构依赖的结构非常复杂。但这是我们应该对OGC采取的措施。 :)你需要一些疯狂的东西，比如十几个模式来读取传感器数据。我实际上打算构建自动加载依赖项，但尚未实现此功能。

下一个GML_3_1_1.AbstractFeatureType问题可能是this issue。尝试更改映射的顺序（将GML_3_1_1移动到更早的位置）。实际上映射的顺序不应该很重要，但是，有一个错误。

交叉检查的工具 - 不，可能不是。我的方法是进行往返测试（unmarshal-marshal-unmarshal-check equality）。根据经验，一开始通常会有一些警告，但它的设计是有效的。当然，Jsonix中存在错误，并且可能存在映射问题，但这可以解决。

还想在这里创建一个支持项目：

https://github.com/highsource/jsonix-support

例如https://github.com/highsource/jsonix-support/s/sos。

以下是此类支持项目的一个示例：

https://github.com/highsource/jsonix-support/tree/master/l/lightstalker89

我需要这个，因为只是从Google云端硬盘下载XML（a）需要我努力设置支持项目（b）具有法律危险性，因为我不知道这个XML来自何处以及我是否有权利/许可来添加这些文件到我的测试套件。