О важности схем XML

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

В первую очередь, мы заметили, что многие разработчики не поставляют, и видимо не имеют, схемы XML (XSD). Это очень большая ошибка. Отсутствие схемы говорит о том, что соответствующие программные модули не используют совсем или используют частично стандартные средства обработки XML, например, Microsoft XML Core Services (MSXML). Что в свою очередь чревато скрытыми проблемами. Но ещё хуже ситуация на принимающей стороне. Разбор XML без схемы сильно увеличивает трудоемкость создания процедуры, приводит к ошибкам при разработке, не позволяет автоматически выполнить проверки правильности заполнения полей, не позволяет следить за версионностью и изменениями. 
XML стал хорошей заменой позиционным файлам не только из-за структурированности данных, но и из-за возможности значительно ускорить разработку его записи и прочтения, переложив множество тяжелых функций на уже существующие в операционных системах решения. Например, IATA перестала развивать позиционные стандарты сообщений Cargo IMP и предлагает всем переходить на стандарты Cargo XML. Но XML без схемы, это по сути всё тот же позиционный файл, только вместо номера строки и номера позиции используется название тэга.
Попытка разработчиков «ускорить» создание процедуры выгрузки простого, как им кажется, XML-файла без проектирования схемы и её применения при процедуре выгрузки в будущем приведет к дополнительным работам. В лучшем случае их руководство заставит их сделать схему и сопровождать её, тем самым выполнять двойную работу. Хуже, если в точках приёма по примерам сделают схему, и будут пытаться её использовать, исправляя каждый раз, когда очередной пример будет ей противоречить. Это неверные технологии производства программных продуктов, и мы призываем от них отказаться, чем раньше, тем лучше.

Далее, имея опыт создания собственных стандартов XML-файлов, которые стали признанными в отрасли, а не только в рамках наших продуктов, мы хотим обратить внимание на именования типов, тэгов, секций и других элементов XML.
У программистов уже давно сложилось понимание, что такое читаемый и нечитаемый исходный код, есть несколько устоявшихся групп правил хорошего кода, например венгерская нотация. Но для всех, кто занимается серьезными и долгосрочными проектами, кто передает свой код на сопровождение другим разработчикам, совершенно ясно, чего категорически не должно быть. Точно также и при проектировании схемы XML необходимо, не желательно, а именно необходимо, придерживаться минимального набора правил именования объектов.
Все имена должны быть написаны в одном удобно читаемом стиле. Имя должно нести в себе смысл объекта так, чтобы не приходилось бы обращаться к документации. Имя должно быть на хорошем английском языке, никакой транслитерации родного языка. Название типа должно быть уникальным настолько, чтобы не было бы проблемы в другой компании использовать ваш тип как часть другой схемы XML, проще всего к названию типа всегда прибавлять один и тот же префикс, соответствующий вашей компании.
Надо помнить, что схема XML или сам XML файл - это открытый код, который вы передаете на сторону. Если вы будете выполнять очевидные правила именования, то ваш продукт получит дополнительные преимущества. Если не будете, то на стороне приема XML или при формировании XML по вашей схеме будет складываться негативное представление о вашей компании в целом. 
 

Остались вопросы?

Оставить заявку

Другие контакты для связи с компанией посмотрите в разделе «Контакты»

Политика Политика в отношении обработки персональных данных.