我正在尝试使用 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。我真的很想了解这是否与我创建上下文时模块的顺序有关,尽管我相信这很好。一旦找到解决方案,我就有两个后续问题。
期望(通常)使用从 highsource github 页面上的 ogc-schemas 构建的模块应该允许我通过 jsonix 处理所有响应是否合理?即每个元素将始终映射到定义的类型。我知道这些模式/映射非常复杂。
是否有任何其他工具可以用来验证模块或根据模式验证它们以使生活更轻松,而不是在 jsonix 似乎解析不正确时逐个跟踪元素或跟踪各种模块文件?
提前致谢 - 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]);