Как получить регистронезависимые элементы в XML

Question

Насколько я знаю имена типов элементов XML, а также имена атрибутов чувствительны к регистру.

Есть ли способ или хитрость для получения нечувствительных к регистру элементов?

Разъяснение : Грамматика была определена через XSD, который используется для загрузки некоторыми клиентами данные. Пользователи - генераторы контента - создают файлы XML, используя разные инструменты, но многие из них используют простые текстовые редакторы или что-то еще. Иногда, когда эти люди пытаются загрузить свои файлы, они получают ошибки несовместимости. Это распространенная ошибка, что они смешивают теги lowerCase и upperCase, хотя это всегда было ясно, что теги чувствительны к регистру.

У меня есть доступ к файлу XSD, который определяет эту грамматику, и я могу ее изменить. Вопрос в том, как избежать этой подверженной ошибкам проблемы тегов нижнего / верхнего регистра.

Есть идеи?

Заранее спасибо!

Answer 1

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

т.е. Файл XML> Проанализировано в XSD и исправлено> Загрузка одобрена

Вы могли бы сделать это во время выполнения, разработав контейнерное приложение для своих клиентов для создания своих XML-файлов. В качестве альтернативы вы можете написать приложение на стороне сервера, которое принимает загруженный файл и проверяет синтаксис. В любом случае вам придется принять решение, а затем сделать какую-то работу !!

Многое зависит от масштаба проблемы. Если у вас есть похожие теги в разных случаях в вашем XSD, например и если вы получаете, то вам понадобится сложное решение, основанное на подсчете узлов и т. д.

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

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

Слишком много способов обсудить это здесь. В основном это зависит от имеющихся у вас навыков и финансов.

Answer 2

Теоретически вы можете попытаться взломать XML-схему для проверки неверно прописных имен элементов.

Это можно сделать с помощью механизма группы подстановки в XML-схеме. Например, если ваша схема определила:

  <xsd:element name="foobar" type="xsd:string"/>

тогда вы можете добавить в схему XML следующее:

  <xsd:element name="Foobar" type="xsd:string" substitutionGroup="foobar"/>
  <xsd:element name="FooBar" type="xsd:string" substitutionGroup="foobar"/>
  <xsd:element name="fooBar" type="xsd:string" substitutionGroup="foobar"/>
  <xsd:element name="FOOBAR" type="xsd:string" substitutionGroup="foobar"/>

и т.д.

чтобы попытаться предвидеть возможные ошибки, которые они могут совершить. Для каждого элемента может быть 2 ^ n возможных комбинаций падежей, где n - длина имени (при условии, что каждый символ имени является буквой).

На практике это слишком много проблем, только задерживает проблему, а не решает ее, и, вероятно, не будет работать. Если пользователи не понимают, что XML чувствителен к регистру, у них могут отсутствовать конечные теги, совпадающие с регистром начального тега, и он все равно не будет проверен.

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

Answer 3

Как сказал @Melkisadek, проверка XSD существует с определенной целью. Если вы разрешите пользователям загружать файлы с недопустимым XML, ваше приложение обязательно завершится ошибкой в ​​какой-то момент при доступе к данным в этих файлах. Кроме того, вся цель проверки XSD входной XML-схемы побеждена. Если вы готовы отказаться от возможности проверки всей схемы, вам потребуется использовать XSLT для преобразования всех тегов в верхний или нижний регистр по вашему желанию (см. Ответ @ Rashmi).

Это было бы аналогично разрешению пользователю вводить специальные символы в поле ввода номера социального страхования, просто потому, что пользователю удобнее вводить специальные символы (да, этот пример глуп, не мог придумать лучшего! )

Поэтому, на мой взгляд, решение заключается в том, чтобы сохранить проверку схемы как есть, но предоставить пользователям способ проверки схемы перед загрузкой. Например, если это веб-приложение, вы можете предоставить кнопку на странице, которая использует Javascript для проверки файла по вашей схеме. Кроме того, проверка на сервере только при загрузке файла. В обоих случаях предоставьте соответствующую обратную связь, такую ​​как номер строки, на которой лежат ошибочные объекты, позиция символа и причина для обозначения ошибки.

Answer 4

Процессоры XPath / Xslt чувствительны к регистру. Они не могут выбрать узел / атрибут, если вы укажете неправильный регистр.

Если вы хотите вывести имя узла и хотите, чтобы оно было в верхнем регистре, вы можете сделать:

upper-case(local-name())

Answer 5

Простое решение отправляется в нижний регистр всех тегов / атрибутов, когда вы загружаете xml от пользователя, и только затем проверяете его поверх xsd, предназначенного для всех строчных тегов / атрибутов

Answer 6

После загрузки пройдитесь по XML-файлу (через DOM или SAX) и исправьте регистр перед проверкой?

Answer 7

XML обычно генерируется машиной. Следовательно, у вас не должно быть реальной проблемы здесь ширина <RANdOm /> case.

Если реальная проблема заключается в том, что две разные системы генерируют два разных типа тега (<Widget /> против <widget />), я думаю, вы можете просто определить оба случая в своем XSD.