Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.
Либо реализовать версионность протокола обмена — либо проблемы клиентов. Имхо так.

Геннадий Васильев wrote:
> Я неудачно сформулировал. Вопрос должен быть таким: что делать, если
> софт у получателя остался прежним, а схема валидации XML поменялась?
> Прилетает совершенно валидное XML-сообщение, к которому не готов софт
> получателя.
В таком случае мы, хотя бы, сразу можем диагностировать ошибку. А вот с
бинарным протоколом может быть что угодно.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась?
А-а, это я неудачно ответил. На самом деле софт, если он построен в расчете на какую-то схему, должен тащить ее с собой. И валидировать документ именно ею. А иначе — да, всё верно, формальная валидация даст не больше пользы, чем IP Checksum.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Sinclair, Вы писали:

ГВ>>>Это при условии, что отправитель не поменял содержимое самой схемы.
S>>Ну, по идее, обе стороны используют одну и ту же схему.

ГВ>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.

А что будет в бинарном?

Здравствуйте, Cyberax, Вы писали:

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

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

C>А вот с бинарным протоколом может быть что угодно.

Бинарные протоколы тоже бывают разные, не стоит обобщать.

Здравствуйте, Sinclair, Вы писали:

S>А-а, это я неудачно ответил. На самом деле софт, если он построен в расчете на какую-то схему, должен тащить ее с собой. И валидировать документ именно ею.

Да, я именно это и имел ввиду. То есть общая проблема согласования версий сообщений остаётся. И в этом смысле совершенно не важно, как именно мы доказываем допустимость обработки конкретного сообщения: посредством схемы или простым сравнением 4-х байт в начале бинарного пакета.

S>А иначе — да, всё верно, формальная валидация даст не больше пользы, чем IP Checksum.

Именно. Она только поможет доказать, что сообщение не покорёжено и соответствует какой-то схеме.

Здравствуйте, aka50, Вы писали:

ГВ>>Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.

A>А что будет в бинарном?

В каком именно?

Геннадий Васильев wrote:
> C>В таком случае мы, хотя бы, сразу можем диагностировать ошибку.
> Это зависит от многих факторов. Например, если добавлены новые узлы, то
> условно "старый" софт их просто проигнорирует, не заморачиваясь
> диагностикой.
Если он при этом пользуется старой схемой/DTD — вылетит с ошибкой валидации.

> C>А вот с бинарным протоколом может быть что угодно.
> Бинарные протоколы тоже бывают разные, не стоит обобщать.
Ну так сложные бинарные протоколы обычно не проще XML.

Здравствуйте, Cyberax, Вы писали:

>> C>В таком случае мы, хотя бы, сразу можем диагностировать ошибку.
>> Это зависит от многих факторов. Например, если добавлены новые узлы, то
>> условно "старый" софт их просто проигнорирует, не заморачиваясь
>> диагностикой.
C>Если он при этом пользуется старой схемой/DTD — вылетит с ошибкой валидации.

Да, если схема/DTD интегрирована в софт. Нет, если она подгружается.

>> C>А вот с бинарным протоколом может быть что угодно.
>> Бинарные протоколы тоже бывают разные, не стоит обобщать.
C>Ну так сложные бинарные протоколы обычно не проще XML.

Вот потому и не надо обобщать, рассуждая об ужасах бинарных протоколов, они бывают — разные.

Здравствуйте, Cyberax, Вы писали:

C>Ну а я писал драйвера для железок, для которых у меня была только
C>спецификация протокола. Больше не хочу.

C>А вот с железками, которые общаются в XML работать вообще просто сказка.
C>Можно писать для них драйверы, просто смотря на wire protocol.

Вообще, не слишком серьёзный аргумент в защиту самого протокола. Ты посмотрел wire protocol, запрограммровал один раз драйвер для него и — всё. А железка продолжает гонять по сети эту уже никому не нужную документацию.

Геннадий Васильев wrote:
> C>А вот с железками, которые общаются в XML работать вообще просто сказка.
> C>Можно писать для них драйверы, просто смотря на wire protocol.
> Вообще, не слишком серьёзный аргумент в защиту самого протокола. Ты
> посмотрел wire protocol, запрограммровал один раз драйвер для него и —
> всё. А железка продолжает гонять по сети эту уже никому не нужную
> документацию.
Так пусть себе гоняет — даже 1000 устройств не загружает 10Mbit-сеть. В
новых версиях XML еще может сжиматься gzip'ом — так там вообще траффик
копеечный.

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

Геннадий Васильев wrote:
> C>Если он при этом пользуется старой схемой/DTD — вылетит с ошибкой
> валидации.
> Да, если схема/DTD интегрирована в софт. Нет, если она подгружается.
Ни разу еще не видел подгрузки схемы/DTD из Сети в production-софте
Так как в этом случае софт будет зависеть от [ненадежного] внешнего
соединения.

>> > C>А вот с бинарным протоколом может быть что угодно.
>> > Бинарные протоколы тоже бывают разные, не стоит обобщать.
> C>Ну так сложные бинарные протоколы обычно не проще XML.
> Вот потому и не надо обобщать, рассуждая об ужасах бинарных протоколов,
> они бывают — /разные/.
Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
подробной документации на досуге написать парсер ASN.1 PER — занятие еще то.

Здравствуйте, Cyberax, Вы писали:

>> Да, если схема/DTD интегрирована в софт. Нет, если она подгружается.
C>Ни разу еще не видел подгрузки схемы/DTD из Сети в production-софте
C>Так как в этом случае софт будет зависеть от [ненадежного] внешнего
C>соединения.

Угу. А я ни разу не видел, чтобы бинарные протоколы не сопровождались средствами контроля версий и целостности данных.

>>> > C>А вот с бинарным протоколом может быть что угодно.
>>> > Бинарные протоколы тоже бывают разные, не стоит обобщать.
>> C>Ну так сложные бинарные протоколы обычно не проще XML.
>> Вот потому и не надо обобщать, рассуждая об ужасах бинарных протоколов,
>> они бывают — /разные/.
C>Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
C>подробной документации на досуге написать парсер ASN.1 PER — занятие еще то.

Что за глупость? Писать парсер без подробной документации по исходным данным?

Здравствуйте, Cyberax, Вы писали:

>> Вообще, не слишком серьёзный аргумент в защиту самого протокола. Ты
>> посмотрел wire protocol, запрограммровал один раз драйвер для него и —
>> всё. А железка продолжает гонять по сети эту уже никому не нужную
>> документацию.
C>Так пусть себе гоняет — даже 1000 устройств не загружает 10Mbit-сеть. В
C>новых версиях XML еще может сжиматься gzip'ом — так там вообще траффик
C>копеечный.

C>Кроме того, пригодность для быстрого анализа и нахождения проблем — это
C>огромный плюс, превышающий копеечную экономию на сети.

Раз на раз не приходится. Я о принципиальной стороне сейчас говорил.

Геннадий Васильев wrote:
> C>Ни разу еще не видел подгрузки схемы/DTD из Сети в production-софте
> C>Так как в этом случае софт будет зависеть от [ненадежного] внешнего
> C>соединения.
> Угу. А я ни разу не видел, чтобы бинарные протоколы не сопровождались
> средствами контроля версий и целостности данных.
Показать?

> C>Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
> C>подробной документации на досуге написать парсер ASN.1 PER — занятие
> еще то.
> Что за глупость? Писать парсер без подробной документации по исходным
> данным?
Неудачно выразился — попробуй написать парсер только по спеке, без примеров.

Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
все. А потом подумай — почему оно почти никому не нужно.

Геннадий Васильев wrote:
> C>Кроме того, пригодность для быстрого анализа и нахождения проблем — это
> C>огромный плюс, превышающий копеечную экономию на сети.
> Раз на раз не приходится. Я о принципиальной стороне сейчас говорил.
Так я и говорю — в большинстве случаев это непринципиально.

Здравствуйте, Андрей Коростелев, Вы писали:

На всякий случай напомню коллегам, углубившимся в ветку: я не думаю, что основная проблема XML — эффективность. Проблема, как я вижу, в том, что он неудобен для решения именно тех задач, для которых предназначался. Он очень сложный, непонятный, и выполнение большинства требований стандарта сулит только геморрой, а не удобство.
Ну вот, к примеру: нельзя трактовать подветку XML как самостоятельный документ. А очень часто требуется именно это: построение композитных документов, где часть мало знает о целом, а целое — о частях. И что? Народ выкручивается: вытаскивает outerXml и приклеивает к нему заголовок. Бред? Бред. Либо хитрит с парсерами, нарушая стандарт.
Про ситуацию с неймспейсами я лучше умолчу, т.к. у меня недостаточно квалификации для полноценного обсуждения, да и тема недавно поднималась.

Sinclair wrote:
> На всякий случай напомню коллегам, углубившимся в ветку: я не думаю, что
> основная проблема XML — эффективность. Проблема, как я вижу, в том, что
> он неудобен для решения именно тех задач, для которых предназначался. Он
> очень сложный, непонятный, и выполнение большинства требований стандарта
> сулит только геморрой, а не удобство.
Так фича в том, что в XML, большей частью, используют только
подмножество стандарта. Примерно как в С++.

Здравствуйте, Cyberax, Вы писали:

C>Ты, видимо, никогда не отлаживал программы с бинарными протоколами.
C>Когда днями приходится искать почему сообщения не проходят — и
C>оказывается, что в checksum считается один лишний байт.
А как им славно сносит крышу, если промахнуться хотя бы на один байт !

На самом деле, основной гемор даже не этот (по моему опыту), а то, что чаще всего их реализовывают в виде чего-нибудь типа

struct PROTOCOL_HEADER { ...  };
PROTOCOL_HEADER hdr;
fread(&hdr, 1, sizeof(hdr), file);

а потом начинаются пляски с выравниванием, byte order'ом и так далее.

Альтернатива -- писать байтовый поток в платформонезависимом виде, а потом долго-долго ручками выписывать stream_read_dword() / convert_network_to_host_dword() и так далее.

Честно говоря, я так и не решил для себя что лучше.

ps. Заюзать что-то типа rpcgen можно, но не всегда, к сожалению.

Здравствуйте, Cyberax, Вы писали:
C>Так фича в том, что в XML, большей частью, используют только
C>подмножество стандарта. Примерно как в С++.
Ну, мне лично это не вполне понятно. В С++, вроде бы, стараются стандарту хотя бы не противоречить. А в в жизни используют эдакий "почти XML", который нельзя назвать XML с точки зрения стандарта.