xPath в 1С

04.03.23

Интеграция - Файловый обмен (TXT, XML, DBF), FTP

Опыт работы методами языка xPath в 1С.

Язык XPath в 1С.

Если кому-то интересно, то попробую поделиться тем, как я использую методы языка XPath в той части, в которой этот язык удалось "внедрить" в 1С.

Основным стимулом, побудившим меня заинтересоваться методами этого парсера (XPath), был достаточно большой размер файлов XML и их значимое регулярное количество. Для справки, файлы от 5 до 10 мБайт в количестве, несколько десятков за сутки. Кто-то из "маэстро бигдаты" может посмеяться над такими размерами и объемами, но мне, как говорится, "для счастья - хватило".

Основным содержимым этих файлов были так всеми нами любимые коды маркировки. А возникающие вопросы выглядели примерно так - "отобрать все серии продукции, где код маркировки от позиции N до позиции NN равен строке 'ABСDE.....' ". При этом должны проверяться файлы, созданные с даты "X" по дату "Y". То есть сотни мегабайт XML. 

Сразу натолкнулся на статью //infostart.ru/1c/articles/415439/

Прочел.... Потом еще много чего находил и читал. Со временем приобрел какой-то опыт, которым и поделюсь.

Итак, "XPath" вещь вполне полезная, а безальтернативность (применительно к 1С) автоматически делает ее самой лучшей. Если есть коллеги, которые еще не пользовались этим механизмом, то для лучшего понимания, определю XPath как "язык запросов для текстов XML". По-моему, вполне похожее определение.  Ведь если взять любую таблицу и начать ее построчно читать, сравнивая поля таблицы с какими-то значениями для поиска необходимого, то в примитивной работе с файлами XML приходится делать то же самое. Открывать текст XML в объекте и пробегаться "по узелкам". Но однажды таблицы баз данных стали огромными, и кто-то придумал язык SQL. Видимо, парсер XPath придумали по аналогичной причине.

А еще, можно по тексту XML создать ДокументDOM, и там тоже есть несколько методов поиска. Но эти методы даже примерно не создают возможностей парсера. И уж если дело дошло до создания ДокументаDOM, то уже надо вовсю использовать парсер XPath, который и "вшит" в объект ДокументDOM, как отдельный раздел методов.

Сам язык xPath я не нашел в документации 1С. Но описаний синтаксиса этого языка и описаний его функций вполне достаточно на самых разных сайтах. Это нетрудно найти и сразу начать пользоваться. А вот специфические "мульки" этого языка в платформе 1С я уже проверил на себе. Чем и делюсь, итак.

1. Метод объекта  ДокументаDOM, с которого начинается поиск (парсинг) выглядит так

"ВычислитьВыражениеXPath(<Выражение>, <УзелКонтекста>, <Разыменователь>, <ТипРезультата>)",

Где 

<Выражение> - это текстовая строка, написанная по стандартам парсера и создющая ось (оси) поиска;

<УзелКонтекста> - стартовая позиция поиска (является элементом, узлом DOM) ;

<Разыменователь> - возможно, специфический объект 1С (я не так уж плотно изучал XPath вне платформы 1С и не могу сказать, есть ли такой объект в этом парсере у других платформ);

<ТипРезультата> - системное перечисление, указывающее на то, в виде чего надо получить результат поиска.

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

Второй параметр не нуждается в описании. Даже если не знать желаемый стартовый узел, то всегда можно написать <ДокументDOM.ЭлементДокумента> и вести поиск от корневого (основного) элемента документа.

А вот третий параметр потребовал много времени на понимание. Это объект <РазыменовательПространствИменDOM >. Что он делает? Вроде бы, все просто, он "пространства разыменовывает". Вернее, должен был бы разыменовывать. Но делает он это весьма своеобразно, я бы даже сказал, капризно. Активно пользуясь парсером XPath, я до сих пор считаю, что именно странное поведение объекта Разыменователь является самой большой заковыркой в парсере для платформы 1С.

Как я понимаю суть разыменования пространств. Это нивелирование (очистка) префиксов имен элементов и атрибутов текста XML.

То есть, привести способ записи имен элементов и атрибутов к режиму простой (неквалифицированной) записи. При наличии элементов, например "skl:Номенклатура", "zvd:Номенклатура" и "mgz:Номенклатура" разыменователь аннулирует их квалифицированные имена (условно сотрет префиксы), после чего все эти элементы будут рассматриваться при парсинге (формированию осей поисков) исключительно по своим простым (безпрефиксным) именам. Хотелось бы, чтобы это было так. На деле, после многодневных мучений выяснилось, что Разыменователь в 1С добросовестно разыменовывает те пространства, которые в платформе 1С числятся "своими или родными". Я иначе это понимание не могу сформулировать. Нельзя сказать, что указаный объект не работает, он безусловно работает, но по какому то заданному набору пространств, как я убедился методом "тыка". Попытка заставить его разыменовывать какие-то иные имена пространств приводит к несложной ситуации. Ошибок нет, разыменования тоже нет! Поэтому! При составлении строки поиска, по которой формируется ось (оси) поиска обязательно пользуйтесь только квалифицированными именами элементов. А вот в отношении атрибутов разыменователь работает в полном объеме! Такой вот казус) Это означает, что если вам нужны элементы с именем "Номенклатура", но такие имена у вас есть в двух и более пространствах (с разными префиксами), вам придется указывать их - все и строка поиска будет выглядеть, например, так: "/skl:Номенклатура|zvd:Номенклатура|mgz:Номенклатура".

Игнорировать объект Разыменователя (параметр как NULL) в методе поиска тоже нельзя, так что придется его создавать перед поиском в любом случае, даже осознавая его бесполезность. Конструктор этого объекта позволяет создать разыменователь для конкретного пространства (набора пространств) имен. Я пользуюсь самым простым вариантом. Я использую вариант конструктора, где  можно указать УзелDOM и объект при конструировании сам узнает - какие пространства есть в конкретном заданном узле. И я указываю весь документ  DOM, вот так <Новый РазыменовательПространствИменDOM(ДокументDOM)>. При таком раскладе разыменователь вроде бы должен "обезфамилить" все имена всех пространств в документе, но такого счастья у меня еще ни разу не получилось. Так что, еще раз напомню, в строке поиска все имена элементов - только квалифицированные! При соблюдении этого условия парсер работает "на ура", отбирает элементы, атрибуты или их содержимое по любым, самым замысловатым условиям отбора, инструментария в синтаксисе и функциях языка xPath вполне хватает.
Теперь о получаемом результате. Из особенностей использования результата поиска отмечу такой момент. Результат поиска не сериализируется, надо "перебирать вручную".

Вот системное перечисление <ТипРезультатаDOMXPath >. Два его значения, а именно <НеупорядоченныйИтераторУзлов >  и <УпорядоченныйИтераторУзлов > предлагают коллекцию найденных значений. Поэтому первым действием будет позиционирование на первый элемент коллекции

 

РезультатПоиска.ПолучитьСледующий();

//И только затем вход в цикл

Пока  РезультатПоиска <> Неопределено Цикл
    //...... строки команд по обработке результата;
    РезультатПоиска.ПолучитьСледующий();
КонецЦикла;

 

На этом, кажется, все. В остальном надо только совершенствовать понимание принципов и закономерностей формирования строк поиска. 

Я активно использую этот парсер вместе с тем методом, который я описывал в своей предыдущей статье. Мне приходилось иметь дело с достаточно сложными конструкциями XML. Если ставить задачу создания, например, пакета XDTO сразу для всего получаемого текста XML, то такой объект получается крайне громоздким, сложным в описании, а главное, бессмысленным, т.к в очень многих случаях из всей этой сложной конструкции, содержащей десятки и сотни элементов, нам из них реально нужны пара-тройка. И вот тут парсер незаменим! Я получаю требуемые мне элементы с помощью парсера, моментально собираю легкую конструкцию СхемыXML, применительно именно к тем элементам, которые я нашел и по такой схеме создаю Фабрику, которая позволяет мне работать уже с полноценным объектом, с заданными типами и .д.

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

xPath XML ДокументDOM

См. также

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134917    722    291    

388

SALE! 20%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

34650 27720 руб.

15.04.2019    68412    178    138    

111

SALE! 20%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Предлагаем приобрести готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

43450 34760 руб.

03.12.2020    34167    80    58    

78

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.87.x) и УТ 11.5 (11.5.16.x).

28000 25200 руб.

23.07.2020    46282    196    64    

157

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9205    9    8    

10

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.223.x) и БП 3.0 (3.0.149.x). Правила подходят для версии ПРОФ и КОРП.

28000 25200 руб.

15.12.2021    20233    132    38    

90

SALE! 10%

Перенос данных из БП 3.0 в УНФ 3.0 / УНФ 1.6. Переносятся остатки, документы и справочная информация

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление нашей фирмой 3.0 Россия Платные (руб)

В продаже с 2018г. | Воспользовались более 41 предприятия! | Правила конвертации (КД 2) для переноса данных из БП 3 в УНФ | Переносятся все виды документов, начальные остатки и вся возможная справочная информация | Есть фильтр по организациям | Оперативно обновляем на новые релизы | Оказываем техподдержку | В комплект файлов входит инструкция, авторская версия обработки "Универсальный обмен...", актуальные правила переноса данных и архив старых версий переноса | Учет в БП 3 должен быть корректным, некорректные данные не переносятся | Можно бесплатно проверить на вашем сервере до покупки!

50722 45650 руб.

10.07.2018    67439    41    122    

46

Загрузка номенклатуры c картинками (несколько потоков одновременно) и сопутствующими данными в базу и любые документы из yml, xls, xlsx, xlsm, ods, ots, csv для УТ 10.3, УТ 11 (все), БП 3, КА 2, ERP 2, УНФ 1.6/3.0, Розница 2

Загрузка и выгрузка в Excel Логистика, склад и ТМЦ Ценообразование, анализ цен Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Платные (руб)

Эволюция не стоит на месте - новая удобная версия функциональной обработки для Вашего бизнеса! Что же Вы получаете? Удобный и интуитивно понятный интерфейс с 3-мя этапами работы. 2 режима - автоматический и ручной. Чтение XLSX, XLSM, CSV, XML/YML форматов без офиса, на любом сервере! Визуальное связывание колонок файла и реквизитов простым перетаскиванием колонок. Создание или обновление номенклатуры с иерархией, характеристик, доп. реквизитов, упаковок, загрузка практически неограниченного количества картинок на одну номенклатуру (с возможностью загрузки в несколько потоков одновременно), с хранением в томах или в базе. Загрузка номенклатуры поставщиков или поиск по их данным номенклатуры. Загрузка доп. реквизитов в характеристики. Загрузка штрихкодов с генерацией новых. Создание элементов справочников и ПВХ "на лету" для выбранных реквизитов. (Обновление от 11.12.2023, версия 9.5 - 9.9)

13200 руб.

20.11.2015    150702    367    375    

501
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Dmitryiv 161 05.03.23 13:43 Сейчас в теме
Да уж! Сколько в своё время часов было потрачено чтобы понять логику работы разыменовывателя....
А так - да! Инструмент очень полезный.
aSHA-1; DemetrKlim; +2 Ответить
2. ixijixi 1775 05.03.23 18:10 Сейчас в теме
Хорошая статья, не хватает практических примеров только
Fox-trot; +1 Ответить
3. DemetrKlim 157 05.03.23 18:57 Сейчас в теме
(2) Сам по себе метод "ВычислитьВыражениеXPath" прост. В нем нечего и описывать особо для примера.
Вся суть этого метода в построении выражения поиска (первый параметр метода).
А практический пример без труда можно создать.
Нужно взять любой текст XML и прежде всего:
1. Определиться - что хочется найти в этом тексте и с какими условиями отбора.
2. Поняв, какие условия отбора требуются, написать строку поиска, используя синтаксис языка xPath.
3. Эту строку зарядить в метод и попытаться получить результат.
Уверен, что с созданием объекта "ДокументDOM" по текстовой строке XML трудностей нет.
А больше ничего и не нужно.
Если при вызове метода не будет возникать ошибка, значит, Вы уже правильно применяете синтаксис. А если результат поиска будет не пустой, то значит, Вы реально-таки что-то нашли.
Поверьте, легче пробовать, чем смотреть в чужие строки и пытаться применять какие-то аналогии. Примеров построения поисковых строк языком xPath в сети - полно и с избытком. Я же ссылку дал на хорошую статью с примерами построения на этом же сайте. Загляните туда. Я просто не стал дублировать то, что на сайте уже есть.
cleaner_it; ixijixi; +2 Ответить
20. ixijixi 1775 09.03.23 09:22 Сейчас в теме
(3)
моментально собираю легкую конструкцию СхемыXML
А вот по этому пункту можете пояснить?
21. DemetrKlim 157 09.03.23 09:34 Сейчас в теме
(20) Я предыдущую статью писал о том, как можно быстро, не имея готового пакета XDTO в конфигурации, програмно собрать (через объект СхемаXML) схему, на базе которой создать уже фабрику. В обсуждении этой моей статьи один из коллег предложил аналогичный метод (программного создания Модели), тоже очень удачный подход. Суть обоих этих подходов в том, что программными средствами (кодом) можно создать некий объект (Схему или Модель), на базе которого уже создается Фабрика.
В каких случаях это может быть полезно. Допустим, есть офигенно сложная конструкция XML, сотни элементов, сложно ветвящихся, да еще и вариативных по структуре (неодинаковая структура, в зависимости от тех или иных условий). Пытаться создать пакет XDTO по такой сложной "плавающей" конструкции долго и объемно (по труду и по размеру). Файл XSD тоже большой и хлопотный, и хорошо, если его кто-то предоставит при обменах. А из такого сложного файла, очень часто, нужен небольшой фрагмент структуры из нескольких элементов. Вот для этих случаев и был вынужден освоить программное создание Схемы (или Модели) для последующего создания компактной специализированной Фабрики.
22. ixijixi 1775 09.03.23 09:48 Сейчас в теме
(21) Спасибо, ознакомлюсь
4. RocKeR_13 1317 06.03.23 09:35 Сейчас в теме
Тоже в свое время знакомился с XPath, но так в ходе практической работы и не довелось, так скажем, подобрать задачу для его использования. Обычно в ходе реализации различных интеграций нужен весь или почти весь объем информации из XML-файлов. Максимум использую ДокументDOM - вот это реально удобный механизм для чтения XML с заранее известной структурой.
5. DemetrKlim 157 06.03.23 10:47 Сейчас в теме
(4) Ну, я тоже обходился "Домом" и его методом поиска элементов по имени. Потом появились тексты с сотнями тысяч одноименных элементов, которых пришлось уже по текстовому содержимому анализировать и иногда этим необходимым оказывался один элемент из сотни тысяч. На этом этапе пришлось осваивать парсер.
6. пользователь 06.03.23 18:48
Сообщение было скрыто модератором.
...
7. DemetrKlim 157 06.03.23 20:25 Сейчас в теме
(6) В плане префиксов или их отсутствия. По тому, с чем я имел дело в плане XML, у меня сложилось вообще нехорошее впечатление. Казалось бы, есть некий, всеми принятый, стандарт. Раз уж сами не догадались придумать вовремя. Ну, так пользоваться надо этим стандартом так, как он авторами задумывался. Из последнего, что я вынужден был ковырять, обмен с ФНС (прослеживаемость РНПТ). Вроде бы солидная госструктура с лучшим, по их же словам, "цифровым администрированием". Ну, так создали бы и нормативно утвердили для всей страны свои имена пространств имен для элементов обмена, с указанием точных префиксов, типов и т.д. Так нет же. Очень многие XML файлы оформляются сугубо от балды. Произвольные имена, любые префиксы - пофиг! Проглатывается. В моем представлении описание любого протокола для XML обмена с этого и должно начинаться. А у нас, как Вы и написали, где-то лепят префиксы, где-то нет, чаще всего, можно и так, и - так. Офигенно строгие протоколы)
Вот только что смотрел в ленте этого сайта. Обмен с Интернет-торговлей нашей. "Родился" новый стандарт "YML")) Стало любопытно - полез смотреть. Оказывается наш любиый Яндекс "изобрел" аналог XML, "только гораздо лучче!". Вот вместо того, чтобы утвердить свое пространство описать там применяемые имена, установить шаблоны структуры для уже существующего XML, начали лепить свой "псевдостандарт", который даже внешне неотличим от XML.
Таким дай волю - в каждой деревне сделают свой стандарт электрической розетки....
8. starik-2005 3033 07.03.23 06:16 Сейчас в теме
(7)
YML

Внимание. Маркет постепенно перестает поддерживать XML. Поэтому мы рекомендуем переходить на JSON. Сейчас XML можно использовать, если добавить в запрос Content-Type: application/xml. Без этого будут ошибки.
9. DemetrKlim 157 07.03.23 07:33 Сейчас в теме
(8) Угу... а потом будет YSON? )) Уже родилось отношения к стандартам (протоколам), Абсолютно детское, типа "Так и быть, буквы мы выучим. Но с правописанием заморачиваться не будем!"
10. starik-2005 3033 07.03.23 09:10 Сейчас в теме
(9) Потом будет протобуф. Но это когда 1С научится HTTP 2.0+
11. DemetrKlim 157 07.03.23 09:32 Сейчас в теме
(10) Суть не в лейбле того или иного стандарта (инструментария). Сам подход. Есть некий нормальный общий подход при любых обменах. Перед тем, как организовывать любое движения, надо сформировать и нормативно закрепить правила этого движения. Я как ни столкнусь с каким-то обменам, так сразу две проблемы. 1. Нет ни одной нормальной документации по обмену (все на живую нитку "ты же профи, ты обязан интуитивно понимать!") 2. Сама информация изначально мало (никак!) упорядочена. Это как разница между алфавитом финикийцев и символьным письмом (иероглифами) египтян. Если финикийцы придумали систему кодирования фонетических звуков, то египтяне оперировали понятийными образами (символами), типа, "видишь ибиса, значит, это - Нил!" Эволюция отдала приоритет способу финикийцев.
У нас перебирают разные форматы (стандарты) обменов (а что толку!), но в любой из них пытаются засунуть понятийные образы (иероглифы), которые нуждаются в дополнительной интерпретации или куче сопроводительной информации
12. starik-2005 3033 07.03.23 09:52 Сейчас в теме
(11)
. Нет ни одной нормальной документации по обмену
НУ я как-то делал какой-то обмен на базе стандарта GraphQL, и у меня не возникло ни одной проблемы. Не было проблем и с более сложным XBRL - там стандарт вообще в нормативку включен и минюстом одобряется. Для всевозможных XML-обменов есть SOAP, в котором зашита XSD-схема, которая уже может считаться технической документацией. С DHL, например, у меня не было проблем - там на чистом английском языке был расписан API во всех нюансах. А вот со CDEK была, но тоже за пару звонков решилось. Так что заявлять, что "нет ни одной нормальной документации по обмену" - это бред.
По поводу "2", то не совсем понятно, к кому это претензия? Если кто-то не смог разобраться с Яндексом, который для 1С даже модуль поставляет, то это чьи проблемы? Уж точно не Яндекса.

В общем, сопроводительная информация есть, просто читать ее уметь надо, а для этого надо быть специалистом, т.е. начинать читать документацию со словарем, а после того, как тезаурус сформируется, можно и без словаря.
13. DemetrKlim 157 07.03.23 10:21 Сейчас в теме
(12) Стандарт, это то, с чем никогда не надо разбираться. Когда я покупаю какой-то гаджет USB мне в голову не приходит проверять цоколевку или схему подключения. Я исхожу из того, что все сделано в стандарте и дополнительных разбирательств не требует.
Каким российским нормативным документом утверждено использование SOAP, как общеприменимого стандарта? Для любого стандарта неприемлема фраза "может считаться...." Это уже переход в понятийные образы и режим "кто тут понятия толкует и масти раздает".
C DHL прекрасный пример! "...расписан API во всех нюансах...." Вот они, "дурачки" из солидных серьезных и очень крупных, разветвленных организаций, тратят время зачем-то - расписывают во всех нюансах. Для таких же дурачков, не иначе (кстати, Эдвина Луканова я знаю больше 50-ти лет, это мой одноклассник). А мы - "страна гениев"! Мы знаем кому надо сделать "пару звонков" и гордимся тем, что "поняли или разгадали (разобрались)" с чьими-то витиеватостями. Когда мне захочется что-то поразгадывать - я куплю журнал с ребусами и кроссвордами. Не скрою - тоже кайфую от этого) В профессиональной деятельности заниматься шарадами и загадками (радуясь их разгадкам!) это только Россия может себе позволить, нас же весь мир - подождет! Нифига в этом ни ума, ни гордости нет. Я большую проблему в том и вижу, что мы утрачиваем (утратили??) компетенции по системным подходам и созданию единых нормативов. Мы - становимся мастерами уникальных творений, без возможностей масштабирования и тиражирования. Поэтому, высокой производительности (основа конкурентоспособности) не достигнем, нам же придется каждый раз пару звонков делать). Я согласен читать только документацию, содержащую универсальные знания. Если в какой-то уникальной деревне решили отказаться от десятичной системы исчисления и перейти на "четырнадцатиричную", я этой фигней ни глаза, ни голову загружать не соберусь.
Очень хорошо, если человек может разгадать путь по хлебным крошкам, про таких уникумов пишут красивые сказки и снимают голливудские боевики, но GPS, как системы, создают немного другие люди.
user658002_SvanMoscow; roman72; +2 Ответить
14. starik-2005 3033 07.03.23 10:23 Сейчас в теме
(13)
Я согласен читать только документацию, содержащую универсальные знания
Ну давайте, приведите пример плохой документации (ссылка). Пока только нытье "мы все просрали" вижу.
23. HAMAZ 7 09.03.23 18:48 Сейчас в теме
(13) Отсутствие опыта общения с REST интерфейсами не доказыает, что этот опыт заранее болезнен-бесполезен. REST успешно используется повсеместно, что не мешает делать при помощи этой архитектуры ужасные интерфейсы. Какой стандарт еще нужен? Уже есть архитектура или соглашение.
SOAP это протокол, что тоже не мешает нагородить при его помощи велосипедов и костылей.
А касаемо "стандартов" АПИ (не отвлекаясь на протоколы/соглашения) - как создать единообразный стандарт обмена (уверен что он будет громоздким и избыточным) с хорошей документацией, чтобы подходил на любой случай, для любой отрасли? Ну, допустим, создали. Откупорили - обмыли. Начали переписывать всё под стандарт. Спрос на кодеров растет, бизнес платит, бюджет пилится) Налицо оптимизация. Все по уму: кантики на тэгах, дерево объектов вечно-зеленое, кодеры ликуют. И что? Уже не нужно мануал к конкретному АПИ искать? Все равно придется. Можно сразу обмен канонический писать? Таки да, но нет! Наличие "святейшего стандарта обмена" не помешает при его помощи застругать франкентшейна коричневого цвета.
В сферическом вакууме - профит колоссальный, на практике - траты на перестроение кучи ИС на новые рельсы и новые грабельные интерфейсы и не менее косноязычную документацию к ним. Ведь существует множество контор, где самый умный не тот, кто умный, а тот кто раньше трудоустроился и ближе к императору сел.
24. DemetrKlim 157 09.03.23 19:08 Сейчас в теме
(23) Мы сейчас сидим и пишем в Интернете, который работает по одной основной причине - наличие правил его работы. Ни одному идиоту не придет в голову перед включением электробритвы в розетку, измерять в ней напряжение - ведь есть же правила (нормы, стандарты, протоколы) и как-то все так привыкли к такой скукоте и чувствуют себя комфортно, ведь электрики "франкенштейнов не строгают", а могли бы!
А свою отрасль кодеры превратили в какую-то тусовку знахарей и ведунов, придумали себе жаргон из языка светлых эльфов и этими словами начали заменять все то, что сами осмыслять не хотят.
А какие "кучи ИС" у нас есть? Честный знак? ЕГАИС? ГИС ЖКХ? Да, освоили кучу денег, накупили эшелоны техники. За все это заплатил бизнес и, умножив на два, все это включил в цену уже для нас, обывателей. Эти информационные системы, что ли, придётся "перепиливать"? А что, на эти системы спрос был? У кого??)
Можно постучаться к соседу (НЕ программисту) и спросить "Сосед! Какой информационной системой вы пользовались за последнюю неделю?" Интересно, что он ответит. В основной массе наши ИС это "наждаки для бизнеса" - чтоб не забывали делиться с кем надо... Собственно, для граждан придумано совсем мало....
user658002_SvanMoscow; roman72; +2 Ответить
25. HAMAZ 7 09.03.23 21:52 Сейчас в теме
(24) электрики ещё как строгают франкенштейнов. Пожарники подтвердят
26. DemetrKlim 157 10.03.23 08:13 Сейчас в теме
(25) Вот именно! Ошибка электрика моментально становится уроном или трагедией. И вот почему. Электричество реально нужно! И гражданам, и предприятиям, и социальной сфере. Поэтому у электриков нет шансов покуражиться и порезвиться - моментально отрабатывает "обратная связь". А с информационными системами все гораздо смешнее. Я в своей городской торгово-промышленной палате на одном из собраний спросил у нескольких десятков руководителей - что они получают и как часто из своих учетных или управленческих информационных систем (те или иные варианты 1С продуктов). И вполне прогрессивные молодые "продвинутые" люди пожали плечами. Апофеозом "приобщения к цифре" для них стало посещение своего "он-лайн банка", ну и получение почты + мессенджеры. Всё! Основной ответ - "Я у бухгалтера спрошу....."
Отсюда вывод. В огромном числе случаев информационная система едва-едва выползает за границы бухгалтерии и то - для быстрой печати красивых бумажек (не вручную же писать!). Поэтому программисты имеют возможность резвиться и куражиться, наш "бизнес" в огромном своем сегменте совершенно не базируется на цифровом фундаменте, IT-отделы работают сами у себя и решают проблемы, которые сами себе и создали)
Конечно, есть сферы деятельности, где инфосистема - необходимое звено. Так там и подходы, и отношение другое. Очень рекомендую посмотреть ролик с форума "IT-Core" (ноябрь 2022). Там собирались в том числе начальники IT-служб наших флагманов индустрии и энергетики. И в выступлении такого топ-менеджера из РосАтома очень мне "зашло". Там еще сохраняется здравость в подходах к смене поколений программных продуктов. А почему? Да потому, что атом не дает шансов порезвиться и поэкспериментировать. Там не приемлем лозунг "давайте попробуем!" И уж тем более, никто даже задачи не ставит "работать по заявкам пользователя".
Вот и у электриков - так же!))
user658002_SvanMoscow; +1 Ответить
28. HAMAZ 7 10.03.23 09:06 Сейчас в теме
(26)
Вот именно! Ошибка электрика моментально становится уроном или трагедией.
Это даже не за уши притянуто. Это откровенно вранье! Ошибка электрика может годами ждать отгорания нуля на КТП.

(26)
Я в своей городской торгово-промышленной палате на одном из собраний спросил у нескольких десятков руководителей
Это в каком году было?

(26)
IT-отделы работают сами у себя и решают проблемы, которые сами себе и создали)
Сразу видно наличие только инхаус опыта работы.

(26)
наш "бизнес" в огромном своем сегменте совершенно не базируется на цифровом фундаменте
торговля кабачками - да, не базируется. Дворовый дежурный магазин тоже. Все, что имеет номенклатуру > 1000 уже обклеено этикетками и лежит на остатках в регистре.

(26)
Там еще сохраняется здравость в подходах к смене поколений программных продуктов. А почему? Да потому, что атом не дает шансов порезвиться и поэкспериментировать.
Вырванный из контекста эпизод это еще не тенденция и тем более не правило.
31. DemetrKlim 157 10.03.23 09:35 Сейчас в теме
(28) Вопрос руководителям задавал лет 7-8 назад. Произошли революционные изменения? Извините, не оповещен)
Насчет "инхаус"-опыта. Не пытайтесь быть психологом или следователем, не имея соответствующего образования и опыта. Мне лет до 30 было "сразу все видно". Получаемый жизненный опыт учит сомневаться даже в изначально очевидном. Я не такой уж высокий профессионал, свое мнение базирую на опыте более образованных граждан. В частности, послушайте (почитайте) выступления (интервью, ответы) Натали Касперской. Или у нее тоже сплошной "инхаус"-опыт? Я всего лишь, сравниваю проявления и события того, с чем уже сам сталкиваюсь в повседневной деятельности, с тем что слышал в ее выступлениях. Она чертовски догадлива! ... Или просто хорошо тему знает, не?
Если РосАтом - это "обрывок эпизода", то я уж не знаю - на кого уповать) Это же не мои слова, а их же руководителя. Это есть в открытом доступе - подлежит просмотру.
user658002_SvanMoscow; +1 Ответить
32. HAMAZ 7 10.03.23 10:13 Сейчас в теме
Окромя демагогии - ничего пока вычитал. Все это похоже на ворчание на поток новых технологий. Не успеваете выучить технологию, на ее осуждение времени хватает.
37. Painted 49 14.03.23 17:41 Сейчас в теме
(26)
Очень рекомендую посмотреть ролик с форума "IT-Core" (ноябрь 2022).
Заинтриговали. ))
А где его взять?
27. HAMAZ 7 10.03.23 08:49 Сейчас в теме
(24)
Какой информационной системой вы пользовались за последнюю неделю?"
Все пользуются информационными системами каждый божий день, даже если не осознают этого. Нужно перевести деньги? Баланс телефона пополнить? Записаться на прием в ПФР или справку заказать на госуслугах? Всё это ИС. И со всем этим происходит взаимодействие посредством API.
И все придумано за нас и до нас. Существует немало архитектур, соглашений, протоколов и паттернов разработки/проектирования, позволяющих специалистам проектировать и разрабатывать API, при этом другие специалисты вполне понимают как это работает.

(24)
Собственно, для граждан придумано совсем мало....
Мало???????? Сейчас можно не выходя из уборной заказать поесть, полетать, ОСАГО, записаться на прием к врачу, купить автомобиль, получить справку о несудимости. Если приглядеться, то сейчас максимально просто получать услуги. Поменять водительское удостоверение это плевое дело - записался в ИС ГОСУСЛУГИ и приехал в назначенное время. Для сравнения - в 1999-м году такая процедура отнимала весь день и клубок нервов. Или вот захотелось вам подарок другу в другом городе сделать - купили на ОЗОНе и пункт выдачи нужный указали...и друг получил подарок при помощи ИС, которую ОЗОН разработал)
Посему вопрос: Что для граждан нужно сделать, кому и в каком масштабе, что бы вы гордо сказали "Для граждан сделано немало!"?
Пока вы мечтаете о том, чтобы обмен информацией между ИС подчинялся ГОСТ и регламентировался как механическая обработка металлов, другие люди освоили новую технологию, написали новый обмен...
29. DemetrKlim 157 10.03.23 09:19 Сейчас в теме
(27) Я же сразу оговорился, что есть сектора и экономики, где без ПО невозможна сама деятельность. Конечно, торговая площадка "ОЗОН" или "ВсеИнструменты" это и есть информационная система, которая есть главная технология и инструмент всей деятельности.
Я имел ввиду по большей части производственную сферу.
Что касается Госуслуг и их аналогов. Лучше бы не упоминали) "Ой, как классно это работает!".... Это мы с чем сравнили? Это мы сколько лет к такому шли? А за сколько нам это обошлось? А у кого-то есть представление - как это должно работать и в какие сроки, и за какие деньги - изготавливаться?
Я стал самозанятым с момента появления такой возможности, в личный кабинет самозанятого "ныряю" ежедневно. И как не было устойчивой интеграции с ПФР, так до сих пор и нет. Прошло три года... Это к вопросу "нафига нам стандарты, мы - умные, мы разберемся и на живую ниточку все сделаем!". Мы газоны косим, надев противогазы. Зачем? А мы - комсомольцы, мы без трудностей не можем!
Наши ИС часто сравнивают с "зарубежом". Типа, у нас такие сервисы, которых на западе и нет совсем. Предмет гордости? Черт его знает... Там тоже неглупые люди живут и если допустить, что у них чего-то нет, то может быть, это и не надо никому? В том смысле, что там халявы меньше и будет только то, за что будет платежеспособный спрос. Да, у нас есть системы, люди им рады... пока! Если гражданам сказать, сколько из их кармана ежегодно надо отдать, чтобы вся эта цифра "жила и процветала", то есть вероятность, что граждане скажут "да ну нафег, я лучше в очереди постою раз в пять лет!" Мы же воспринимаем все эти "госуслуги", как нечто бесплатное, правда? А что, ЕГАИСы, ВЕТИСы, Платоны и другие "Честные знаки" уже не включены в цену готовой продукции и услуг, за которые мы, все, дружно платим? А что, граждане так просили ЕГАИС? Я допускаю существование вполне состоявшегося "цифрового лобби", которое уже какое-то время назад проложило свой благоустроенный канальчик от широкой реки бюджета и регулярно открывает створы для получения очередной дозы. "На что там еще маркировки нет? Открывай задвижку!"
Как раз вчера (до сих пор в тренде, кажется) новость о вводе нового электронного документа "провозной документ" (путевой лист). Я в автотранспорте и перевозках (при нефтепродуктах) провел 15 лет. Это был предмет моей профессиональной деятельности - документооборот автоперевозок. Я прочел разработанный фНС стандарт - кровь из глаз!! Сам факт того, что стандарт провозного документа разрабатывает не Минтранс, а налоговики о чем говорит? Откуда Мишустин пришел? На волне чего он поднимался - за что его хвалили? За лучшую информационную систему налогового администрирования! Совпадение? Не думаю)
Хорошая информационная система возникает, как объективная потребность, как ответ на существующий реальный спрос населения или бизнеса. У нас огромное число "цифры" возникает как проект освоения бюджета. Поэтому и результат - так себе....
user658002_SvanMoscow; +1 Ответить
30. HAMAZ 7 10.03.23 09:33 Сейчас в теме
Просто Мишустин, будучи явным крипторептилоидом, в 2001 году придумал JSON, чтобы в России в 20-х годах пилить бюджеты на написании ИС.
33. DemetrKlim 157 11.03.23 11:27 Сейчас в теме
(30) То есть, "масок-шоу" в том же Ланите не было? Если перечислить все эти расхваленные информационные системы и предложить их отменить после опроса среди бизнеса? Сколько из этих ИС бизнес очень попросит оставить действующими? Какие еще признаки навязывания никому не нужных ИС еще нужно предъявить? А если создали никому не нужные ИС, то кто и зачем инициировал их создание?
можно постебаться какое-то время, но на стебе разговор не вывезешь...
34. HAMAZ 7 12.03.23 18:38 Сейчас в теме
а начиналось с ворчания про разнообразие архитектур, протоколов, соглашений...как тяжко программисту с сединой с джейсоном басурманским ковыряться) Но надо, надо в сервис постучаться, скрывая от коллеги XML
39. DemetrKlim 157 14.03.23 18:57 Сейчас в теме
(34) Я уже несколько "молодых" оконфузил, предложив, банально, занять позицию "упор лежа") Пока выяснялось, что кроме цифры в паспорте ничем иным "молодость" меня не потрясла)) То, в чем мне приходилось разбираться, большинство молодых "гениев" обескуражило бы гораздо сильнее, чем меня озадачил вполне понятный "Джейсон". Для справки - маразм наступает куда как позднее, А ссылка на возраст - самый убогий аргумент в споре, как минимум - не этичный.
15. DemetrKlim 157 07.03.23 11:27 Сейчас в теме
(14) Э-э... мне надо привести пример того, чего нет? Это как я должен сделать?) Но несложно. Вы похвалили документацию по API DHL. Я её не видел, но вполне верю Вам, что она подробно расписана. Вот ее и возьмем, как образец хорошего. А с второй стороны, из последнего, что я помню, давайте попробуем найти документацию на API ФНС (в части сервиса прослеживаемости - РНПТ). Положите рядом два этих текста. Уверен, что разница будет очень заметна. А ведь это государственный сервис, обязательный по Федеральному законодательству.
Вот подзаконный акт, как-то описывающий "работу" обязательной для всех участвующих, системы прослеживания. "Постановление Правительства РФ от 1 июля 2021 г. N 1108 “Об утверждении Положения о национальной системе прослеживаемости товаров”""
Вроде бы мы дружно идем в цифровизацию, подразумевается машинная обработка информации и т.п. При этом же, в таких важных нормативных документах даже попыток не делают сформулировать - как это будет в цифре реализовано! Типа того, "мы вам понятийный образ сформировали, а остальное отдано на откуп программистам, как эти художники увидят, так оно и будет!". Правительство, само, стандарт не удосужилось описать (или прямо указать на использование какого-то уже существующего стандарта (стандартов)!), в обязанность программистам-разработчикам обязанность по созданию, описанию и нормативному оформлению стандарта тоже не вменена. В итоге - кто создаст и опубликует описание, как комплект документов, пригодных для работы остальных участников информационной системы? Ведь никто, при текущей сложившейся ситуации, не обязан этого делать. И вот умники по всей стране демонстрируют свою уникальную догадливость, форумы кипят, саппорты на грани коллапса. Неужели нравится такой режим работы?
На мой взгляд, Федеральные законы и подзаконные нормативные документы, подразумевающие свое участие в информационных системах, обязаны проходить некий "цифровой аудит" еще в Госдуме (или Правительстве) на предмет стандартов их "цифровой эксплуатации". Раз есть такой нормативный документ, то он уже на этапе утверждения обязан быть снабжен хорошо задокументированными схемами, шаблонами. протоколами, интегрирующими его в информационные системы, а не короткой строчкой "программисты потом напридумают чего-нить". Должно быть доступное место хранения таких схем, шаблонов, документации и т.п. А не по форумам собирать обрывки легенд и сказаний народа навахо. Программисты уже по готовым чертежам должны работать, а не загадки друг-другу задавать-разгадывать.
16. starik-2005 3033 07.03.23 12:58 Сейчас в теме
(15)
API ФНС
https://api-fns.ru/api_help - дальше...
ЗЫ: Документация DHL - это просто унылое г-но по сравнению с тем, что я нашел по ссылке. У DHL описывается XSD-схема, а здесь REAT-API с полным описанием и примерами, чего в DHL нет, но там оно и не нужно, ибо XSD - это стандарт. Сравните. И да, теперь у них GraphQL. Поздравляю.
А плохому танцору - да, ботинки жмут всегда.
17. DemetrKlim 157 07.03.23 13:52 Сейчас в теме
(16) Надоело спорить. Я привел пример по сервису прослеживаемости. На этой ссылке я был в поисках документации по упомянутому мной сервису. Вы смогли найти описание протокола обмена по прослеживаемости в этой ссылке? Вот и я не увидел.
Стандарт (протокол) это не размещение на какой-то ссылке непонятно кем сформированного текста. Это процедура. В постановлении правительства есть явная отсылка, что, дескать, "все шаблоны, протоколы и стандарты размещены на федеральном ресурсе... таком-то"?
Или по принципу, "что святой Гугль нашел, то и правда"?
Да хрен бы с ним, с госстандартом. Но в шатах, например, есть какое-то неправительственное коммерческое (но ЕСТЬ!) NST. Как некий накопитель и администратор того, что напридумывали люди и хотят это сделать общеупотребимым. У нас от ГОСТов отказались (по факту), альтернативы никакой не создали и все надеждя и чаяния только на мастерство "танцоров"?
18. starik-2005 3033 07.03.23 15:00 Сейчас в теме
19. DemetrKlim 157 07.03.23 16:47 Сейчас в теме
(18) Не оно... Да не ищите, правда. Меня эта тема напрямую коснулась, поверьте, я плотно полазил по всем возможным местам. Вот это и выбешивает. Почему я должен, как порнушку, искать стандарты обмена в информационной системе, ОБЯЗАТЕЛЬНОЙ к использованию?? Почему единственный лоскуток информации дают, как ссылку на какой-то ФОРУМ(!!!), где что-то там, типа "выложено". Если интересно, то в файле то, что с трудом наковырялось в сети. Если это стандарт, то я - Гендальф Серый)
Прикрепленные файлы:
Описание интерфейсов Открытых API (Потребитель).docx
35. Fuego 462 13.03.23 09:41 Сейчас в теме
Просто использование XPath не решает проблему большого объема данных....
При работе с большими файлами лучше использовать смешанную модель доступа к данным в XML - нужно вычитывать некоторые единицы в последовательном режиме (ЧтениеXML), а считанные данные для удобства объектной работы использовать в DOM-модели (ДокументDOM).
Кроме того, автор статьи, по всей видимости, совсем новичок в запросах XPath, на что указывает желание удалять префиксы имен узлов. Иногда это, действительно, требуется, но делается иначе. Разыменовыватель, если не ошибаюсь, используется для определения пространств имен по префиксам, используемым в запросе. Я использую другой подход, который работает всегда внятно:
xmlNode = xmlDocument.selectSingleNode(".//*[local-name()='TRAN_DRIVER' and (namespace-uri()='http://fsrar.ru/WEGAIS/TTNSingle_v3' or namespace-uri()='http://fsrar.ru/WEGAIS/TTNSingle_v2')]");

Здесь в примере используется MSXML2, но сути запроса не меняет. В запросе используются функции XPath, которые возвращают конкретные значения независимо от используемого префикса в XML. И соответственно, в запросе не завязываюсь на какие-либо префиксы, ибо разные системы их могут формировать по своему усмотрению автоматически.
36. DemetrKlim 157 13.03.23 20:16 Сейчас в теме
(35)
Кроме того, автор статьи, по всей видимости, совсем новичок в запросах XPath,

Аффтор как раз в возрасте "новичка") А что Вам показалось моим желанием "удалять префиксы"? Да, я встречал и такой подход, когда граждане с помощью простого метода "СтрЗаменить" устраняли все префиксы в тексте, по принципу - "Нет префиксов - нет проблем"))
Как раз наоборот. С моей точки зрения, префикс это часть стандарта XML. Мне никогда не нравилось упрощение и опошление стандартов, созданных умными людьми. Вопрос в другом. Сколько информационных обменов у нас вообще производятся в рамах каких-то мало-мальски оформленных пространств имен? Согласитесь, что пространства имен чаще всего пишутся "от балды", т.к. "что-то же приходится писать в заголовках файлов XML". Отсюда и бессмысленность применения префиксов - если они вообще ничего не отражают в тексте. У той же ФНС уже куча API по самым разным направлениям и что, где-то можно ознакомится с предписанными пространствами имен таких обменов? Отсюда и подход "...разные системы их (префиксы) могут формировать по своему усмотрению автоматически..." Не автоматически, а произвольно, то есть - "от балды".
Я ни в коем случае не призывал бы уничтожать префиксы. А что делает Разыменователь в 1С я не могу сказать по причине его "хитрой работы" и в этом не только я убедился. Я высказал предположение - что (по моему мнению !) собирался делать этот разыменователь.
Насчет "смешанной модели доступа к данным". Вот тут я не очень понял. Если вы взялись читать файл в последовательном режиме, то весь его и так и прочитаете. А после того, как прочитали - зачем вообще DOM создавать? Вы же при последовательном чтении желаемые узлы уже в какой-то массивчик загнали или как-то еще отобрали необходимые элементы.
Я не занимался лабораторными исследованиями в этом вопросе. У меня был опыт, связанный с маркированной продукцией. Был режим последовательного чтения узлов, а потом я попробовал DOM и xPath. И просто замерили время исполнения одной и той же операции в двух версиях обработки. С большим отрывом победил xPath. После чего я просто перестал терзаться сомнениями. Вот и все.
38. DemetrKlim 157 14.03.23 18:18 Сейчас в теме
(37) С Уважаемой Натальей я "дружу" в соцсети "Вконтакте". Она мне ролик туда скинула. Может и в Ютубе есть, но я там не искал.
ВКонтакте
40. e.kogan 1892 01.04.23 20:10 Сейчас в теме
41. DemetrKlim 157 03.04.23 12:04 Сейчас в теме
(40) Прочел уже после публикации своей. Мне очень понравилось изложение. Если бы натолкнулся раньше - свое не писал бы уже.
Оставьте свое сообщение