Почему информационные системы продолжают обмениваться XML и что проверять при получении документа. Объясняем структуру, схему и значение полей без синтаксиса.
Когда документ пришёл, но его ещё нужно понять
Представим условный обмен между складской системой и службой доставки. Один документ содержит сведения об отправлении, получателе и нескольких коробках. Простой список значений без пояснений быстро становится неоднозначным: непонятно, какой адрес относится к человеку, а какой — к складу, где заканчиваются сведения об одной коробке и начинаются данные следующей.
XML — текстовый формат представления структурированных данных. Он позволяет явно выделять части документа и их вложенность. Встреча с XML в давно работающей системе сама по себе не говорит о её неисправности. Сначала нужно понять действующий договор обмена: что передают стороны, по каким правилам и как получатель проверяет результат.
Теги обозначают границы и названия частей
Тег можно представить как подпись на разделе папки. Он помогает выделить элемент документа, внутри которого находятся значения или другие элементы. Дополнительные свойства могут описывать этот элемент подробнее. По объяснению W3C, XML задаёт правила структурирования данных, а не команды для выполнения программы.
В условном отправлении раздел получателя объединяет имя и адрес, а раздел коробок содержит несколько повторяющихся частей. Вложенность сохраняет принадлежность сведений: адрес внутри получателя не нужно угадывать по соседству с другими словами. Но сами подписи ещё не объясняют бизнес-смысл. Например, дата может означать создание, отправку или плановую доставку — это требует отдельного описания.
Почему внешне похожие документы могут различаться
Две системы способны использовать одинаковое название для разных понятий. У склада «номер» может обозначать отправление, а у перевозчика — отдельную коробку. Пространства имён помогают различать словари элементов, даже если короткие названия совпадают. Этот механизм определён в спецификации W3C Namespaces in XML.
Это похоже на уточнение, какому отделу принадлежит папка с надписью «заказы». Однако пространство имён не заменяет смысловое согласование. Командам всё равно нужно решить, какие номера сопоставляются, в каких единицах указан вес и что означает отсутствие необязательного раздела. Правильное чтение текста файла — только начало обмена.
Схема задаёт допустимое устройство
Схема документа описывает, какие элементы разрешены, какие обязательны и какие значения допустимы. Например, у отправления должен быть получатель, число коробок не должно задаваться произвольной фразой, а повторяющихся частей может быть несколько. XML Schema Primer объясняет назначение схемы как описание класса допустимых документов.
Сначала можно проверить, что XML вообще правильно построен. Затем — соответствует ли он согласованной схеме. Эти проверки различаются. Документ может иметь корректное устройство XML, но не содержать обязательного получателя. И даже прошедший схему документ может ошибочно описывать реальность: допустимая дата не доказывает, что посылку действительно отправили.
Условный пример изменения договора обмена
Допустим, склад передавал вес коробки в килограммах, а после изменения обмена начал передавать граммы. Само число по-прежнему выглядит допустимым. Если получатель продолжит понимать его по старым правилам, ошибка возникнет даже при успешном чтении документа. Поэтому вместе со структурой нужно согласовывать единицы и версию правил.
В другом учебном случае появился новый обязательный раздел. Старый отправитель его ещё не создаёт, и получатель отклоняет документ. Это не повод незаметно выкинуть проверку. Полезнее установить, какие версии поддерживают обе стороны, и согласовать переход. Изменение одной программы может потребовать изменения обмена у её партнёров.
Что выяснить при подключении источника
Предлагаемый набор вопросов: где описание полей, какая схема действует, какие разделы повторяются, как обозначены пропуски и как сообщается об отказе? Отдельно стоит проверить кодировку текста — правило представления символов — и убедиться, что названия не исказились при чтении. Нужны как удачные примеры, так и документы, которые должны отклоняться.
После приёма следует сверить содержимое с задачей: все ли отправления дошли, не потерялись ли коробки, одинаково ли поняты даты и вес. Для такого контроля пригодится подход из статьи о сверке источника и результата. Способ получения данных тоже важен: многостраничная выдача API может требовать отдельной проверки полноты независимо от формата документа.
Зачем это инженеру данных
Инженер данных должен связать описание формата с реальным смыслом записей. XML делает структуру явной, схема позволяет проверять часть договорённостей, но корректность обмена требует ещё и понимания полей. Наличие более нового интерфейса не делает перенос безопасным автоматически: обязательства между системами нужно сохранить.
Изучать получение, преобразование и проверку сведений из разных систем можно на программе Data Engineer для начинающих. Начать полезно с небольшого учебного документа и объяснения словами: что означает каждая часть, кому она принадлежит и как понять, что получатель прочитал её правильно.
