通过 JSONIX 解组 SOS DescribeSensor 响应产生不完整的对象
Unmarshaling SOS DescribeSensor response via JSONIX yields incomplete object
我正在尝试使用 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_语言，当然还有 SensorML_1_0_1)。在我添加这些之前，我注意到 return 是一个通用的 json（请参阅第一个屏幕截图，尤其是 sml:physicalsystem 附近）。添加依赖项后，在我不理解的部分解组过程中，我的控制台出现错误（参见第二个屏幕截图）。这里有一条来自服务器的link到xml的响应，供参考。 https://drive.google.com/file/d/0B8LdnPVJpHz7M3VGb0FZc2lQcjQ/view?usp=sharing。我真的很想了解这是否与我创建上下文时模块的顺序有关，尽管我认为这很好。找到解决方案后，我有两个后续问题。
是否合理地期望（通常）使用从高源 github 页面上的 ogc-schemas 构建的模块应该允许我通过 [=43= 处理所有响应] 好吗？即每个元素将始终映射到定义的类型。我知道这些schemas/mappings很复杂。
我可以使用任何其他工具来验证模块或根据模式验证它们以使生活更轻松，而不是在 [=43 时逐个跟踪元素或跟踪各种模块文件=]ix 似乎解析不正确？
提前致谢 - 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]);
免责声明：我是jsonix and main dev of ogc-schemas的作者。
首先，你走在正确的轨道上，坚持下去。
是的，如果您拥有所有必需的映射，那么您应该得到一个 "nice" JSON，其中包含具有特定类型、基数等的所有属性。
Jsonix 的目标是提供具有确定性结构、类型和基数的双向 XML<->JSON 转换。
OGC Schemas 的目标是为所有 OGC 模式提供 JAXB 和 Jsonix 映射。
所以这两个一起应该允许转换任何 OGC XMLs from/to JSON.
"Generic JSON" 实际上只是 DOM。如果 属性 允许 DOM 而 Jsonix 没有对某个元素进行映射，则将其视为 DOM。您只是缺少 SensorML 映射。
你说得对，模式依赖的结构非常复杂。但这是我们应该向 OGC 提出的问题。 :) 有点疯狂，你需要，比如，一打模式来读取传感器数据。我本来打算构建自动加载依赖项，但尚未实现此功能。
下一个 GML_3_1_1.AbstractFeatureType 问题可能是 this issue。尝试更改映射的顺序（将 GML_3_1_1 移到更早的位置）。其实映射的顺序不应该很重要，但是，嗯，有一个错误。
用于交叉检查的工具 - 不，可能不是。我的方法是做往返测试（unmarshal-marshal-unmarshal-check equality）。根据经验，开始时通常会有一些注意事项，但随后它会按设计工作。当然 Jsonix 中有 bug，映射也可能有问题，但这已经解决了。
也觉得在这里创建一个支持项目：
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 驱动器 (a) 下载 XML 需要我努力设置支持项目 (b) 在法律上是危险的，因为我不知道这个 XML 来自，如果我有 rights/license 将这些文件添加到我的测试套件中。
我正在尝试使用 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_语言，当然还有 SensorML_1_0_1)。在我添加这些之前，我注意到 return 是一个通用的 json（请参阅第一个屏幕截图，尤其是 sml:physicalsystem 附近）。添加依赖项后，在我不理解的部分解组过程中，我的控制台出现错误（参见第二个屏幕截图）。这里有一条来自服务器的link到xml的响应，供参考。 https://drive.google.com/file/d/0B8LdnPVJpHz7M3VGb0FZc2lQcjQ/view?usp=sharing。我真的很想了解这是否与我创建上下文时模块的顺序有关，尽管我认为这很好。找到解决方案后，我有两个后续问题。
是否合理地期望（通常）使用从高源 github 页面上的 ogc-schemas 构建的模块应该允许我通过 [=43= 处理所有响应] 好吗？即每个元素将始终映射到定义的类型。我知道这些schemas/mappings很复杂。
我可以使用任何其他工具来验证模块或根据模式验证它们以使生活更轻松，而不是在 [=43 时逐个跟踪元素或跟踪各种模块文件=]ix 似乎解析不正确？
提前致谢 - 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]);
免责声明：我是jsonix and main dev of ogc-schemas的作者。
首先，你走在正确的轨道上，坚持下去。
是的，如果您拥有所有必需的映射，那么您应该得到一个 "nice" JSON，其中包含具有特定类型、基数等的所有属性。
Jsonix 的目标是提供具有确定性结构、类型和基数的双向 XML<->JSON 转换。
OGC Schemas 的目标是为所有 OGC 模式提供 JAXB 和 Jsonix 映射。
所以这两个一起应该允许转换任何 OGC XMLs from/to JSON.
"Generic JSON" 实际上只是 DOM。如果 属性 允许 DOM 而 Jsonix 没有对某个元素进行映射，则将其视为 DOM。您只是缺少 SensorML 映射。
你说得对，模式依赖的结构非常复杂。但这是我们应该向 OGC 提出的问题。 :) 有点疯狂，你需要，比如，一打模式来读取传感器数据。我本来打算构建自动加载依赖项，但尚未实现此功能。
下一个 GML_3_1_1.AbstractFeatureType 问题可能是 this issue。尝试更改映射的顺序（将 GML_3_1_1 移到更早的位置）。其实映射的顺序不应该很重要，但是，嗯，有一个错误。
用于交叉检查的工具 - 不，可能不是。我的方法是做往返测试（unmarshal-marshal-unmarshal-check equality）。根据经验，开始时通常会有一些注意事项，但随后它会按设计工作。当然 Jsonix 中有 bug，映射也可能有问题，但这已经解决了。
也觉得在这里创建一个支持项目：
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 驱动器 (a) 下载 XML 需要我努力设置支持项目 (b) 在法律上是危险的，因为我不知道这个 XML 来自，如果我有 rights/license 将这些文件添加到我的测试套件中。