Целесообразно ли использовать не-ASCII (естественный язык) теги XML?

Question

Уместно ли использовать теги XML (имена элементов), написанные на не-ASCII естественных языках? Спецификация XML позволяет это (см. Имена и Исключения ), но я не смог найти лучшие практики по этому поводу на W3C и связанных страницах.

Мне нужен практический совет относительно того, какие инструменты поддерживают это, могут ли важные технологии, связанные с XML, такие как XSLT и XForms, иметь проблемы с этим и т. Д.

Я думаю, что Андрей и Томалак упускают суть. XML не обязательно читают программисты, его читают многие профессионалы. Поэтому аргументы, сравнивающие его с исходным кодом, необязательно применяются.

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

Итак, вернемся к вопросу: с какими инструментальными ограничениями я столкнусь? (Eclipse поддерживает UTF, поэтому написание xpaths не будет проблемой.)

Чтобы люди начали работать в техническом направлении, которое мне бы хотелось: в нескольких системах мы использовали методы генерации, чтобы обеспечить идеальное соответствие между XML-схемами, Java-бинами и схемами баз данных.

• Java: в этой статье говорится, что с Юникодом все в порядке
• Oracle: идентификаторы могут содержать только буквенно-цифровые символы из набора символов вашей базы данных
• Мне нужно проверить, какие инструменты мы используем (JibX, Dozer, Hibernate, JXPath ...)

Answer 1

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

Если ваша цепочка инструментов не может проанализировать теги на этом языке, то как вы можете быть уверены, что она правильно обрабатывает контент?

Программистам всегда придется изучать язык целевой области, будь то финансы, генетика, инженерия или болгарская правовая система. Компромисс юзабилити для удобства программиста - почти всегда «плохая вещь». Какое бы усилие ни было сэкономлено, оно в конечном итоге теряется из-за снижения производительности конечного пользователя и затрат / поддержки в течение всего срока службы продукта.

Answer 2

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

Это поможет отделить инструменты, поддерживающие XML, от инструментов, которые утверждают, что это так, и которые на самом деле этого не делают.

Answer 3

Краткий ответ: Вы можете называть свои элементы XML любым удобным для вас способом.

Немного более длинный ответ: если вы хотите использовать наиболее переносимый / поддерживаемый XML, вам, вероятно, следует использовать имена элементов только для ASCII. Я не могу представить себе веской причины использовать другие символы в имени элемента, и это, безусловно, помогает иметь дело с XML во всех видах мест.

Подумайте об обработке узлов XML с помощью некоторого языка программирования, который не обязательно имеет свои файлы исходного кода в кодировке UTF-8. Вам будет трудно писать рабочие выражения XPath, например, на таком языке. Или сопровождающие / программисты, которые не говорят на языке, на котором написаны имена ваших элементов, но отвечают за исходный код. Например, вы запираетесь, когда имена ваших элементов написаны кириллицей. Имена элементов должны иметь структуру и значение, и нет очевидной причины, которая исключала бы ASCII для этой цели.

Answer 4

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

Для меня, я думаю, вы должны хранить все свои XML-данные на болгарском языке, используя набор символов UTF-8. Но в атрибутах, а не в структуре тегов XML.

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

Это может позволить вам создать довольно общий формат файла (подумайте о том, который может быть использован в США или Японии - даже если вы не планируете это делать на самом деле, ваши изменения в разработке гибкого файла) формат будет больше)

Это может быть сложнее. Вы должны быть готовы к работе с противоречивыми, неполными или иным образом плохими данными. Но ты все равно должен это делать. И вы тоже можете быть вознаграждены: формат файла может быть более чистым и ориентированным на будущее, что сделает ваше программное обеспечение более гибким. А может и нет. Обратите внимание на мальчиков, здесь можно. Это на самом деле зависит от ваших конкретных компромиссов дизайна.

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

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

Answer 5

с какими инструментальными ограничениями я столкнусь?

Если я правильно помню, набор разрешенных символов в именах XML изначально отличался в XML 1.0 и XML 1.1, последний из которых допускал также некоторые ранее исключенные сценарии для Юго-Восточной Азии. В пятой (= последней) редакции рекомендации XML 1.0 произошли изменения, и теперь разрешенные символы имени совпадают. Таким образом, по крайней мере теоретически возможно, что некоторые инструменты, которые, как утверждается, совместимы с XML 1.0, будут иметь проблемы с этими новыми разрешенными символами, если они проверяют правильность имени символа и соответствуют только четвертому изданию XML 1.0 .

Но в вашем случае эта проблема является чисто теоретической, если вы используете только ASCII и болгарские символы.

Answer 6

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

Проверьте пример как показано ниже.

<user name="hero">     
  <address>
     <street></street>    
  </address>    
</user>

спасибо.