Ошибка при проверке CheckXML

[Slay]

Соврал... схемой отбивает. Только в протоколе пишет на англицкий манер "Аттрибут не определен..."

[Slay]

Вот два варианта пачки... разделители на значение "источник" влияют значительно...

[Ирина55]

Я не обижаюсь, а удивляюсь. Когда возникают ошибки типа незакрытого тега или блока, все понятно - программа контроля не может понять структуру. Но если структурно xml-файл верный я не понимаю, почему нельзя выдать диагностику на отсутствие (или присутствие лишнего) конкретного блока, а тем более элемента. Я не одна пишу такие проблемы. Но на все один ответ - какой программой формировали файл. Какая разница, если CheckXML - программа для всех. И зря вы говорите только о программистах. Пользователям больших программ еще хуже - они звонят в техподдержку 1-С или Паруса и не могут внятно сформулировать ошибку, а поэтому с ними и разбираться не будут.

[Slay]

Пользователи вообще не понимают результаты проверки... и это не есть гут...

[lubezniy]

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

Мне не хочется отвечать за разработчиков алгоритмов проверки CheckXML (тем более что делаются сами проверки не в Бухсофте). Но чисто из академического интереса попробуйте сделать хотя бы простейший разбор текста на отсутствие и присутствие лишних символов (путём сравнения с оригиналом) и посмотрите, во всех ли 100% случаев алгоритм выдаст Вам точную ошибку, что и где отсутствует или лишнее. У меня по старой работе такая задача лет 9 назад стояла, и промахи были регулярными, хоть попаданий и было гораздо больше. Может, я, конечно, молодой и зелёный, но за 5 лет работы с тем проектом мне не удалось сделать алгоритм, корректно отрабатывающий все ситуации (как то отсутствие множества символов, перемешанные символы и т. п.) без вмешательства человека. При всём при этом там я мог техническими средствами ограничить наиболее каверзные ошибки и этим в разумных пределах пользовался. А здесь этого нужно избегать, бо никогда не знаешь, что за файл пользователь подсунет. Да и как предложите отображать подобные сообщения о структурных ошибках так, чтобы они были понятны и пользователю, и программисту без необходимости знать формат едва ли не наизусть?

Я не одна пишу такие проблемы. Но на все один ответ - какой программой формировали файл. Какая разница, если CheckXML - программа для всех.

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

[Ирина55]

Спасибо.