Модуль VLСверкаПФ не работает

[lubezniy]

Версия обновлена. В ходе решения вопроса с атрибутами и файлами "только чтение" также реализована долгожданная работа с файлами во вложенных папках (включается флажком).
А теперь хотелось бы вынести на обсуждение следующий вопрос - скорее, к программистам. Вчера получил несколько файлов, которые криво обрабатывались программой (в некоторых случаях - вплоть до вылета с исключением) и в то же время нормально открывались в Internet Explorer и Firefox и проходили проверку программой CheckXML. Ручное изучение файлов показало суть кривой обработки: после имён элементов ДатаЗаполнения и СтраховойНомер стоят пробелы как в открывающих, так и в закрывающих тэгах:

<СтраховойНомер >123-456-789 01</СтраховойНомер >
<ДатаЗаполнения >01.01.2001</ДатаЗаполнения >

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

[vk65]

Версия обновлена. В ходе решения вопроса с атрибутами и файлами "только чтение" также реализована долгожданная работа с файлами во вложенных папках (включается флажком).

Обогнали. Я сегодня тоже написал чтение вложенных папок, правда, без рекурсии.

Ручное изучение файлов показало суть кривой обработки: после имён элементов ДатаЗаполнения и СтраховойНомер стоят пробелы как в открывающих, так и в закрывающих тэгах:

Я этот вопрос поднимал ещё месяц назад, при объяснении причин зависания "псковской программы".

<СтраховойНомер >123-456-789 01</СтраховойНомер >
<ДатаЗаполнения >01.01.2001</ДатаЗаполнения >

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

Думается, вопрос однозначный.
1. Википедия. Если в именах элементов пробелов быть не должно, они должны отсутствовать не только внутри имени, но и в начале или конце. Ведь не говорится, что имя может начинаться с пробела, или им заканчиваться.
2. Спецификация. Тут ещё нагляднее.

STag ::= '<' Name (S Attribute)* S? '>'

Отдельно показаны открывающая и закрывающая скобки, пробелы не предусмотрены.
Вывод: правильнее всего включить проверку на пробелы в checkXml, тогда проблема разрешится сама собой.

[lubezniy]

На самом деле, в открывающем тэге пробел служит разделителем имени элемента и его атрибутов. Это есть даже в файлах ПФР (ПачкаВходящихДокументов). Главный вопрос - по закрывающим тэгам.

[vk65]

На самом деле, в открывающем тэге пробел служит разделителем имени элемента и его атрибутов. Это есть даже в файлах ПФР (ПачкаВходящихДокументов). Главный вопрос - по закрывающим тэгам.

Но сути вопроса это не меняет
А вдруг кому-нить захочется делать так: < СтраховойНомер >
А с выводом Вы согласны?

[vk65]

реализована долгожданная работа с файлами во вложенных папках (включается флажком).

procedure TMain_Form.OnShow (Sender: TObject);
нужно добавить:
Subdirs_CheckBox.Checked := Config.Subdirs;

[WDT1950]

включен в CheckXML.
[/url]

Спасибо, что включили ! Просьба еще обновлять ее там своевременно.
Сегодня, 16.07.2011, скачал более свежую CHECKXML, а там устаревшая программа VLSVERKAPF.EXE за 28 июня, хотя есть уже улучшенная за 11 июля.

[lubezniy]

Но сути вопроса это не меняет
А вдруг кому-нить захочется делать так: < СтраховойНомер >
А с выводом Вы согласны?

Меня смутили два момента.
Первое - в спецификации по end-tags (чуть дальше) прописано:

End-tag
[42]   	ETag	   ::=   	'</' Name S? '>'

Что означает S с вопросительным знаком, я, по правде говоря, не понял. Если S означает string, а вопросительный знак - любое количество символов в строке, то ладно.
Второй момент осознаётся, если от формализма перейти к практике. В бизнесе существует понятие обычаев делового оборота. На простой русский в нашем контексте оно переводится примерно как "мало ли что написано, все так делают". IE открывает, Firefox открывает, CheckXML не ругается - ну и? Если это случай из разряда единичных, можно до лучших времён списать его на производственные издержки, вписав потенциальную несовместимость с файлами, сформированными такой-то программой, с указанием способа устранения. Если не единичный, придётся или сделать какую-то предобработку, или переписать парсер (т. е., серьёзно повозиться).

[lubezniy]

procedure TMain_Form.OnShow (Sender: TObject);
нужно добавить:
Subdirs_CheckBox.Checked := Config.Subdirs;

Точно, прошляпил. В следующей версии будет исправлено.

[LoraK]

Второй момент осознаётся, если от формализма перейти к практике. В бизнесе существует понятие обычаев делового оборота. На простой русский в нашем контексте оно переводится примерно как "мало ли что написано, все так делают". IE открывает, Firefox открывает, CheckXML не ругается - ну и? Если это случай из разряда единичных, можно до лучших времён списать его на производственные издержки, вписав потенциальную несовместимость с файлами, сформированными такой-то программой, с указанием способа устранения. Если не единичный, придётся или сделать какую-то предобработку, или переписать парсер (т. е., серьёзно повозиться).

Уважаемый Виктор! Внимательно слежу за Вашим и vk65 творчеством и сотрудничеством. К сожалению, не пишу в Delphi и пока не пользовалась Вашей программой по причине отсутствия времени, а также её неактуальности для меня в связи с наличием программы собственной разработки (на 1С). Однако хочу высказать свое мнение. Т.к. года два назад самой пришлось "рисовать" файл XML, и файл был сформирован криво именно про причине несоответствия открывающих и закрывающих тегов формату: <ИмяТега>Значение</Имятега> (просто прошляпила ), полагаю, что это случай единичный (взять хотя бы статистику от Sova64) и Вам переписывать парсер не нужно. Ведь у большинства все работает. Большинство страхователей пользуются стандартными программами (Смоленск, Оренбург, Башкирия), распространяемыми ПФ. А такие как я, Михаил Иванович, BlackFox и многие другие, пользующиеся собственными программами, подобные ошибки с тегами не допускают, или же должны их исправить. Правила на то и правила, чтобы им соответствовать. Посему возмущает вольное обращение с форматом страхового номера (123-456-789-12 вместо утвержденного 123-456-789 12 ).
Считаю, что Вам не надо тратить время на то, чтобы программа работала на орбите, под водой, в жерле вулкана и т.п., поскольку вероятность использования её в таких условиях равна нулю!
А проверку на отсутствие пробелов в тегах - включить в ЧЕКХМЛ !

[vk65]

Что означает S с вопросительным знаком, я, по правде говоря, не понял. Если S означает string, а вопросительный знак - любое количество символов в строке, то ладно.

Ситуация несколько хуже:

2.3 Common Syntactic Constructs
This section defines some symbols used widely in the grammar.
S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.

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

[Definition: The end of every element that begins with a start-tag MUST be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:]

можно сделать вывод, что так правильно: <tag >x</tag >,
а вот так неправильно: <tag>x</tag >.
То есть, с поиском закрывающего тэга вроде особых проблем нет. Проблема в том, что, встретив внутри открывающего тэга пробел, вы ожидаете атрибут, а его нет. Хотя, тоже в принципе решаемо - можно искать " >". Но при этом время обработки может увеличиться в разы.

IE открывает, Firefox открывает, CheckXML не ругается - ну и?

То, что браузеры нормально воспринимают - это вообще вопрос вторичный. А вот что будет, если в ПФР создадут какой-нибудь новый проверочный комплекс и ошибки посыплются там. Особенно, после того, как чек выдал "Успех".

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

Только неизвестно, сколько существует программ, которые так формируют.

Если не единичный, придётся или сделать какую-то предобработку, или переписать парсер (т. е., серьёзно повозиться).

Я лично полностью согласен с мнением LoraK. Могу только добавить. На данный момент можно выдавать сообщение типа "не найден закрывающий тэг </ИмяТэга>", чтобы пользователю было понятно, в чем проблема.

[vk65]

А проверку на отсутствие пробелов в тегах - включить в ЧЕКХМЛ !

А с этим может возникнуть проблема: разработчики чека часто говорят, что не имеют права добавлять проверки, которых нет в ТЗ.

[lubezniy]

Уважаемый Виктор! Внимательно слежу за Вашим и vk65 творчеством и сотрудничеством. К сожалению, не пишу в Delphi и пока не пользовалась Вашей программой по причине отсутствия времени, а также её неактуальности для меня в связи с наличием программы собственной разработки (на 1С). Однако хочу высказать свое мнение. Т.к. года два назад самой пришлось "рисовать" файл XML, и файл был сформирован криво именно про причине несоответствия открывающих и закрывающих тегов формату: <ИмяТега>Значение</Имятега> (просто прошляпила ), полагаю, что это случай единичный (взять хотя бы статистику от Sova64) и Вам переписывать парсер не нужно. Ведь у большинства все работает.

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

Большинство страхователей пользуются стандартными программами (Смоленск, Оренбург, Башкирия), распространяемыми ПФ. А такие как я, Михаил Иванович, BlackFox и многие другие, пользующиеся собственными программами, подобные ошибки с тегами не допускают, или же должны их исправить. Правила на то и правила, чтобы им соответствовать. Посему возмущает вольное обращение с форматом страхового номера (123-456-789-12 вместо утвержденного 123-456-789 12 ).

Если уж на то пошло, формат страхового номера прописан лишь для отдельных документов в давно не действующем, хоть и не отменённом приложении 3 к 192п (формат 4.0). Формы СЗВ-6 к этим документам не относятся. Впрочем, в прошлой ветке была ссылка на Екжанова, где он объяснял, почему CheckXML в своё время начал пропускать такие номера. Повторяться не стоит.

А проверку на отсутствие пробелов в тегах - включить в ЧЕКХМЛ !

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

[lubezniy]

Ситуация несколько хуже:
Вопросительный знак означает, что элемент может присутствовать, но не обязан.
А если понимать дословно вот это:
можно сделать вывод, что так правильно: <tag >x</tag >,
а вот так неправильно: <tag>x</tag >.
То есть, с поиском закрывающего тэга вроде особых проблем нет. Проблема в том, что, встретив внутри открывающего тэга пробел, вы ожидаете атрибут, а его нет. Хотя, тоже в принципе решаемо - можно искать " >". Но при этом время обработки может увеличиться в разы.

Поэтому я думаю насчёт предобработки. Если время обработки увеличится в большие разы лишь для тех файлов, которые содержат пробелы (вернее, whitespaces) в тэгах, это не будет очень существенно: таких страхователей сравнительно немного. Для остальных же файлов - смотря во сколько раз.

То, что браузеры нормально воспринимают - это вообще вопрос вторичный. А вот что будет, если в ПФР создадут какой-нибудь новый проверочный комплекс и ошибки посыплются там. Особенно, после того, как чек выдал "Успех".

Вообще говоря, таких извращенцев, как я, использующих свои парсеры, мало. Microsoft-овский парсер, используемый в IE и, если я не ошибаюсь, CheckXML, корректно переваривает такие вещи. Проблемы по нему лишь две: работа только с файлами и многообразие версий, осложняющее развёртывание (насколько я понимаю, эта проблема портит кровь пользователям CheckУфа и программ, в которые она встроена).

Только неизвестно, сколько существует программ, которые так формируют.

Неизвестность - это плохо.

Я лично полностью согласен с мнением LoraK. Могу только добавить. На данный момент можно выдавать сообщение типа "не найден закрывающий тэг </ИмяТэга>", чтобы пользователю было понятно, в чем проблема.

В общем, будем думать, экспериментировать и смотреть.

[vk65]

Поэтому я думаю насчёт предобработки. Если время обработки увеличится в большие разы лишь для тех файлов, которые содержат пробелы (вернее, whitespaces) в тэгах, это не будет очень существенно: таких страхователей сравнительно немного. Для остальных же файлов - смотря во сколько раз.

Естественно, только содержащих пробелы из-за того, что строка с данными может из-за этого многократно просматриваться до самого конца.
В принципе, если искать закрывающий тэг не как '</' + B + '>', а как '</' + B, он найдётся по-любому, а потом при желании можно проверить, есть ли у него пробелы перед '>'.
И мне кажется, что если выдавать об этом предупреждение, хотя бы общее, а не по каждому тэгу, есть вероятность, что автор конкретной программы формирования поправит вывод у себя, и общее количество таких программ со временем уменьшится.

[lubezniy]

В принципе, если искать закрывающий тэг не как '</' + B + '>', а как '</' + B, он найдётся по-любому, а потом при желании можно проверить, есть ли у него пробелы перед '>'.

Это смотря как построить файл. На такой вот конструкции, скорее всего, будет завал.

<ИвановИван>
 <ИвановИванИванович>
 </ИвановИванИванович>
</ИвановИван>