我在谷歌搜索中找不到任何相关内容，但我远非XMPP专家，所以答案显而易见。我想知道解析没有显式命名空间的自定义子元素的最佳方法。在这种情况下，我正在解析一些jingle元素，其中一些没有任何显式命名空间（例如，payload-type或parameter，它们没有显式声明命名空间而只是继承它）。
例如：
<description maxptime="60" media="audio" xmlns="urn:xmpp:jingle:apps:rtp:1">
<payload-type name="opus" clockrate="48000" id="111" channels="2">
<parameter value="10" name="minptime" />
<parameter value="1" name="useinbandfec" />
</payload-type>
...
</description>
这里，payload-type和parameter都将从description（urn:xmpp:jingle:apps:rtp:1）继承父命名空间。但参数也可以在其他地方使用：
<source ssrc="1789460357" xmlns="urn:xmpp:jingle:apps:rtp:ssma:0">
<parameter value="mixed" name="cname" />
...
</source>
此处，参数将具有urn:xmpp:jingle:apps:rtp:ssma:0 namspace。
在向ProviderManager添加自定义提供程序时，它需要传入一个显式名称空间，因此我不能只传入一个空字符串（ProviderManager.addExtensionProvider显式检查它）。
一个选项是注册parameter提供程序，例如，在每个可能的命名空间下注册，但这感觉不太好。
另一个选项是更高级别的提供程序（具有显式名称空间的提供程序）解析任何没有名称空间的嵌套子元素，而不是仅递归地获取相应的扩展提供程序并调用parse。看起来像使用ProviderManager注册所有东西是更为惯用的方法。这可能会使用某种内部版本的提供程序管理器，它只能在名称上工作。因此，元素首先会在官方ProviderManager中查找匹配的内容，然后尝试其内部版本。
有没有惯用的方法来实现这一目标？也许我完全错过了什么？
我确实在this question中看到了名称空间是预期的，但我没有在Jingle RTP spec中看到任何名称空间。所以也许我上面提到的一个想法是正确的，但我想知道哪个最适合图书馆。
由于