Наш проект получает из исходного XML этого вида:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <appSettings>
    <add key="foo" value="default">
    ...
  </appSettings>
</configuration>

Затем он читает / анализирует этот XML с помощью ElementTree, а затем для каждого параметра приложения, соответствующего определенному ключу («foo»), записывает новое значение, котороеЭто знает о том, что обратный процесс этого не делает (в этом случае ключ «foo» должен иметь значение «bar»).

вниз по течению процесс, потребляющий отфильтрованный XML, аааааа ...хрупкое, Он ожидает получить XML вименно так форма выше.

Если я проанализирую этот XML без регистрации пространства имен, то ElementTree искажает мое дерево следующим образом:

<configuration xmlns:ns0="urn:schemas-microsoft-com:asm.v1">
  <runtime>
  <ns0:assemblyBinding>
    <ns0:dependentAssembly>
      <ns0:assemblyIdentity culture="neutral" name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
      <ns0:bindingRedirect newVersion="7.0.0.0" oldVersion="0.0.0.0-6.0.0.0" />
    </ns0:dependentAssembly>
  </ns0:assemblyBinding>
 </runtime>
 <appSettings>
    <add key="foo" value="default">
    ...
 </appSettings>
</configuration>

Последующий процесс не может справиться с этим, потому что он недостаточно умен, чтобы осознать, что семантически это одно и то же. Итак, я решил зарегистрировать пространство имен, которое, как я знаю, обратный поток предоставит как пространство имен по умолчанию, чтобы префиксы не появлялись повсюду, и теперь я получаю следующее:

<configuration xmlns="urn:schemas-microsoft-com:asm.v1">
 <runtime>
  <assemblyBinding>
    <dependentAssembly>
      <assemblyIdentity culture="neutral" name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
      <bindingRedirect newVersion="7.0.0.0" oldVersion="0.0.0.0-6.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
 </runtime>
 <appSettings>
    <add key="foo" value="default">
    ...
 </appSettings>
</configuration>

Я не очень разбираюсь в XML, но это еще и нижестоящий компонент, и мне кажется, что это не означает, что это значение по умолчаниюxmlns теперь применяется квсе включенные элементы внутри<configuration>тогда как до этоготолько применяется к<assemblyBinding> элемент?

Там в любом случае,используя ElementTree, чтобы обработать это пространство имен, чтобы я мог взять в верхнем XML, установитеfooзначение, а затем передать его в нисходящий поток, не перемещая пространство имен и не оставляя его таким, каким я его нашел?

Я мог бы использовать решение на основе lxml, которое, кажется, справиться с этим,тем не мениеУ lxml есть зависимость от C, которую нижестоящий компонент действительно не хотел бы поддерживать: предпочтительным является решение на чистом Python.

Я мог бы читать документ как HTML, который игнорировал бы атрибут namespace, позволял мне манипулировать желаемым значением и затем передавал документ;тем не мениеМне еще предстоит найти синтаксический анализатор Python, который не преуменьшает значения всех имен элементов, и мой нижестоящий компонент требует, чтобы регистр для всех имен элементов был сохранен.

Я мог бы прибегнуть к разбору строк и регулярных выражений. Я бы предпочел не писать свой собственный парсер.

Единственный совет, который я мог найти до сих пор об обработке пространства имен в ElementTree, предлагает подход «зарегистрировать пространство имен по умолчанию, чтобы избежать префиксов», который, как я предположил, подойдет, но ElementTree затем настаивает на перемещенииxmlns объявление до корневого узла при сбросе.

Я также мог бы быть умным построить строку, которая выводит дерево поэтапно и в точно правильном порядке, чтобы поставитьxmlns декларация обратно на «правый узел», но это также поражает меня как чертовски хрупкое.

Кому-нибудь удалось преодолеть такую ​​проблему?