Алгоритм как читать описание XML-схем

Рассмотрим уже ставшую стандартной ситуацией, когда на сайте профильного ФОИВа размещается та или иная xml-схема.

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

Но есть и те кто уделяет внимание прочтению соответствующего описания. И молодцы.

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

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

Как правило, основные элементы XML-схем (XSD) включают:
1. Элементы (<xs:element>) - определяют структуру элементов в XML-документе.
2. Типы данных (<xs:simpleType>, <xs:complexType>) - определяют типы данных, которые могут использоваться в элементах и атрибутах.
3. Атрибуты (<xs:attribute>) - определяют атрибуты, которые могут быть использованы в элементах.
4. Ограничения и правила (<xs:restriction>, <xs:pattern>, <xs:enumeration> и т.д.) - определяют ограничения на значения элементов и атрибутов.

В XML-схемах (XSD) обязательные элементы и атрибуты обозначаются с помощью следующих атрибутов:
1. Обязательные элементы.
Для элементов используется атрибут minOccurs:
- minOccurs="1" - элемент обязателен (должен встречаться хотя бы один раз).
- minOccurs="0" - элемент необязателен.
Если minOccurs не указан, по умолчанию он равен 1 (элемент обязателен).

2. Обязательные атрибуты.
Для атрибутов используется атрибут use:
- use="required" - атрибут обязателен;
- use="optional" (по умолчанию) - атрибут необязателен.

Вывод:
- элемент обязателен, если minOccurs="1" (или не указан).
- атрибут обязателен, если use="required".
Если элемент/атрибут не помечен как обязательный, он считается необязательным.

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

По поводу наших коллег, они молодцы конечно, что в своих наблюдениях уделяют внимание наименованию элементов и атрибутов в той или иной схемы, и ведут просветительскую работу по этому поводу, но чтобы лишний раз не напугать себя и окружающих, все таки необходимо еще и обращать внимание не только на русскоязычное наименование элементов и атрибутов, но и на условия их обязательности/необязательного, т.е. на наличие в minOccurs="0" или "1" и наличие в use="required" или "optional".

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

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

Если вы ранее относились сознательно к описанию здания на проектирование по формам 307/пр и 125/пр (бюджетники), то больших сложностей у вас процесс описания задания не вызовет. Ну максимум несколько раз через непереводимую игру слов с использованием местных идиоматических выражений выразите свое отношение к этому «увлекательному» процессу. А дальше научитесь.

И еще, не забывайте проверять результат на checkxml.gge.ru, не ограничиваясь только встроенной проверкой на ЕЦПЭ. Ибо ошибок на ЕЦПЭ может и не быть, а вот на внешнем сервисе они найдутся.

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

Еще есть хорошее презентация «XML для чайников» от наши коллег из СПбГАУ. Видео ищите на просторах зимнего BIM форума.

О нашей работе с 21 по 25 апреля 2025 года:
---
В продолжение (а то и в развитие) темы автоматизации строительного контроля госзаказчика: на уходящей неделе мы сверстали связи между контрольным таблицами с данными нескольких отделов областного УКС и оформили получившийся результат в сводную таблицу.
Туда попали как условно постоянные (наименование подрядчика, номер контракта, размер ЛБО и т.п.), так и динамические данные (кассовые расходы помесячно, количество рабочих на объекте, фактический выпуск рабочей и исполнительной документации).
Все постоянные и часть динамических данных легко собрались через функции вертикального и горизонтального просмотра Excel.
Для сбора сведений о подготовке рабочей и исполнительной документации мы написали скрипт, переводящий цвет ячейки в hex-код, который (в свою очередь) можно использовать как переменную в формуле.
Этот же скрипт пригодился и при сборе проблемных вопросов: специалисты УКСа назначили 85 контрольных точек на этапе от начала ПИР до ввода объекта в эксплуатацию, и красят соответствующую ячейку красным цветом, если плановая задача на этой точке не выполнена. Скрипт позволяет «собрать» только окрашенные ячейки, а далее формула объединяет текст проблемных вопросов и через спецсимвол переноса строки (Alt+Enter) складывает результат в одну ячейку.
Самой интересной задачей стало собрать информацию о количестве людей на площадке. В функцию «ЕСЛИ» мы вложили 5 других функций, и в итоговую ячейку автоматически попадает информация о числе рабочих на текущий день. Если куратор УКСа ещё не заполнил данные о рабочих, то в ячейке стоит значок крестика. А если заполнил, то щелчком мыши на число пользователь может перейти по гиперссылке на источник этой информации.
Разумеется, были и трудности, вызванные культурой ведения таблиц и общим уровнем компьютерной грамотности, и приведшие к сбоям работы формул, а именно:
– применение множества пробелов для красивого размещения текста в ячейке;
– объединение ячеек;
– опечатки.
Если кураторы согласятся с общим видом таблицы и методикой обновления данных в ней, то мы оптимизируем формулы для её удобного администрирования, а также соберём все значимые данные в единую базу данных – пусть не полноценную, но достаточную для решения повседневных задач.
Кроме этого, работая с данными совместно, ИТРы смогут развить насмотренность и сформулировать внятные требования к PLM-системе.

Поклонимся великим тем годам – и поздравляем всех с Днём Победы! 🥂✨

Записи трёх докладов с выставки Securika Moscow 2025:
1. Александр Зайцев. «Проектная документация» в текущих нормах – о чём идёт речь?
Почему возникают сложности с проектной документацией при проектировании и монтаже систем противопожарной защиты на действующих объектах?
Какова разница между проектной и рабочей документацией? Исторический аспект регулирования этого вопроса.
Проблема несовпадения требований МЧС РФ и Минстроя РФ – путаница и сложности в практике.
2. Денис Григорьев. Проблема отсутствия проектной документации на эксплуатируемых объектах. Почему инспектора ГПН это тоже касается?
Правовые аспекты и нормативные требования, обязывающие иметь проектную документацию.
Пути восстановления утраченной документации – через экспертные организации, застройщиков или нормы ГрК РФ.
3. Евгений Озеров. Раздел 5 подраздел «Сети связи» vs Раздел 9 «Мероприятия по обеспечению пожарной безопасности» – что не так с ПП РФ 87?
Недостатки правил оформления проектной документации.
Евгений Игоревич предложил модифицировать 9 раздел проектной документации, разбив его (для большей гибкости) на подразделы.
Необходимость взаимодействия между МЧС РФ и Минстроем РФ для устранения противоречий в нормативных требованиях.
#ПИР #пожбезопасность #лекция

С 25 по 30 мая в Нижнем Новгороде пройдёт финал Чемпионата «Профессионалы».
Общая численность участников финала – более 3000 человек, из них 195 – конкурсанты. Свердловскую область представят 4 конкурсанта.
---
В компетенции «Технологии информационного моделирования BIM» до финала дошёл студент Екатеринбургского монтажного колледжа Айдар Гакашин.
Оппонентами Айдара в финале станут 9 конкурсантов в рамках студенческого моделирования из других регионов.
---
Мы уверены в высоком уровне подготовки команды Свердловской области. Поэтому желаем финалистам удачи, наставникам спокойствия, а победит пусть сильнейший 💪

Подробнее о команде Свердловской области можно почитать здесь.

Кое-что о нашей работе за неделю с 19 по 23 мая 2025 года:
---
Благую весть сообщила Анастасия Гусева на еженедельной оперативке у нашего замминистра Антона Шафаростова: уже несколько узких специалистов областного УКСа в дополнение к чертежам начали работать с цифровыми информационными моделями (ЦИМ).
Сподвигнуть коллег к такому переходу на новый уровень Анастасии удалось как словами, так и наглядными примерами «отловленных» в ЦИМ ошибками проектирования:
– канализационная труба, размещённая ниже уровня подвесного потолка;
– вентиляционный короб, нижняя грань которого идет буквально в сантиметре от подвесного потолка;
– пересечения разнообразных трубопроводов с воздуховодами.
И если пересечения сетей по большей части вызваны несогласованностью в работе смежников (хотя где в этом случае работа ГИПа?), то пересечения с подвесными потолками напрямую связаны с особенностями 2D-документации – при традиционном проектировании высота подвесного потолка указывается в тексте, и для выявления ошибок приходится сопоставлять чертежи с текстом. А в ЦИМ эту ошибку видно сразу, даже без использования автоматизированных поисковых наборов.
Также важно добавить, что несмотря на то, что вышеперечисленные примеры Анастасия выявила на моделях, «поднятых» по чертежам – т.е. даже от таких моделей удалось получить пользу. Хотя вопросы о том, почему всего этого не увидели сами проектровщики – хоть исполнители, хоть ГИП – остаются.
---
Продолжаем работу над отладкой связей контрольных таблиц Excel для областного УКСа – и уже успели доработали их до приемлемо-функционального состояния.
Теперь в сводной таблице обобщена информация о:
1. Проблемных вопросах по объекту. Кураторы ведут таблицы, где в отдельный столбец расставлены контрольные точки. В случае закраски ячейки красным цветом её текст автоматически попадает в графу «Проблемы» таблицы для руководства. Для решения задачи мы написали скрипт, понимающий цвет ячейки как условие формулы «Фильтр».
2. Количестве работников подрядчика на объекте. Также как и в предыдущем случае, формула собирает информацию из трёх других таблиц, но здесь её условием является не цвет, а текущая дата. Эту задачу Алексей Андрейченко решил через формулу «Индекс»+«Сегодня».
3. Освоении бюджетных средств. Здесь была трудность с получением данных, т.к. название объекта записано в объединённой (несколько строк в одной) ячейке, а в следующем столбце могут быть от 10 до 13 строк с направлением расходования средств.
Ввиду непостоянства числа строк формула «Индекс» не подходила, а задавать размер диапазона массива в зависимости от признаков Excel не умеет. Выкрутились через спрятанный столбец с формулой, присоединяющей назначение платежа к названию объекта.
4. Согласовании разделов РД и подписании исполнительной (ИД) документации, необходимых для оплаты СМР. По каждому объекту кураторы ведут таблицу в формате сметы контракта с отметками о выпуске «в производство работ» соответствующего тома/раздела РД и наличии ИД.
Если всё документы в наличии, то в отчётную таблицу попадает символ ✓. На этом этапе основная трудность – единообразие данных, т.к. при объединении всех таких таблиц об объектах в одну таблицу столбцы с данными должны иметь одинаковый адрес, а наполнение ячеек – стандартизованный текст.
На предстоящей неделе УКС собирается проверить работу таблиц и сформулировать дальнейшие потребности.
---
Дополним, что при взаимодействии с плановым отделом УКСа выяснилось, что обобщённые данные об объектах хранятся только в таблицах Excel на основе ручного переноса данных из 1С, системы «Смарт бюджет» и ЕИС в сфере закупок.
Планируем разобраться в этих источниках данных и помочь настроить автоматизацию, т.к. тот же 1С даже «из коробки» умеет автоматически отправлять необходимый отчёт на почту.