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

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

Лучший способ решить проблему — не допустить ее появления.
Сделайте так, чтобы на клиентах всегда была последняя версия бинарников и тогда описанная проблема forward-compatibility рассосется сама собой.

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

O>Вообще, вопрос как бы хорошей практики использования XML — принято ли так делать или нет.
O>Я вот о чем — при добавлении новой опции лучше запихнуть ее в один из уже существующих
O>атрибутов XML-документа (чтобы не ломать обратную совместимость), или же сам разбор XML
O>изначально нужно сделать как бы нестрогим, чтобы новые узлы или атрибуты не трактовались как
O>ошибки чтения конфигурации ? Очень надеюсь, что изложил понятно.
Управление версиями в XML возможно, хоть и сложно. По этой теме есть интересная статья: Versioning XML Vocabularies. Есть перевод: Управление версиями XML-словарей.

O><status id="4" name="Action" color="#4080FF" options="timer;video" />

O><status id="4" name="Action" color="#4080FF" timer="on" video="on />

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

Всем привет ! Хочу поинтересоваться мнением специалистов, да и вообще
интересны любые высказывания по существу вопроса.

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

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

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

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

Спасибо за внимание.

Немного дополнительной информации для примера.

Есть модуль, его записи в файле конфигурации выглядит примерно так:

<status id="4" name="Action" color="#4080FF" options="timer" />

Поле options было специально зарезервировано для "фич".
Теперь мы добавили видео, конфигурация приняла такой вид:

<status id="4" name="Action" color="#4080FF" options="timer;video" />

Кривовато, конечно. Но старые модули "проглатывают" эту запись — они знают
про timer, а video просто игнорирует. Сам формат XML остался нетронутым.

Однако коллега говорит, что так совсем неправильно и что в XML изначально
как бы заложена возможность расширения. То есть, лучше было бы сделать вот так:

<status id="4" name="Action" color="#4080FF" timer="on" video="on />

И XML-парсинг, мол, не нужно делать строгим, то есть привязывать сильно к самому
формату XML — просто игнорировать неизвестные атрибуты.

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

L>Лучший способ решить проблему — не допустить ее появления.
L>Сделайте так, чтобы на клиентах всегда была последняя версия бинарников и тогда описанная проблема forward-compatibility рассосется сама собой.

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

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

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

Добавьте в XML метаинформацию, по которой модули бы могли понять, нужно им это или нет.

<config xmlns:meta="metainfo.xsd">
    <module id="a">
        <parameter id="1" value="1"/>
        <parameter id="2" value="2"/>
        <parameter id="3" value="on" meta:from_version="2.0"/>
        <parameter id="3" value="of" meta:to_version="1.9"/>
        <parameter id="4" value="5" meta:ignore_from="2.1"/>
    </module>
</config>

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


O>><status id="4" name="Action" color="#4080FF" options="timer;video" />

O>><status id="4" name="Action" color="#4080FF" timer="on" video="on />

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

Неохота признавать, но, видимо, Вы правы.

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

L>Лучший способ решить проблему — не допустить ее появления.
L>Сделайте так, чтобы на клиентах всегда была последняя версия бинарников и тогда описанная проблема forward-compatibility рассосется сама собой.

Так сделать невозможно по ряду причин. Модули распостраняются только среди подписанных на обновление и
к тому же в разное время суток (и это зависит от политик, установленных администраторами на местах).
Ну Вы понимаете — система большая, развернута в большом количестве офисов...
Просто физически невозможно сделать единоразовое синхронное обновление и модулей, и спецификаций.
Пока система будет обновляться, некоторые компоненты будут простаивать в аварийном состоянии.

Но все равно спасибо за полезный совет !

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

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

O>>Вообще, вопрос как бы хорошей практики использования XML — принято ли так делать или нет.
O>>Я вот о чем — при добавлении новой опции лучше запихнуть ее в один из уже существующих
O>>атрибутов XML-документа (чтобы не ломать обратную совместимость), или же сам разбор XML
O>>изначально нужно сделать как бы нестрогим, чтобы новые узлы или атрибуты не трактовались как
O>>ошибки чтения конфигурации ? Очень надеюсь, что изложил понятно.
R>Управление версиями в XML возможно, хоть и сложно. По этой теме есть интересная статья: Versioning XML Vocabularies. Есть перевод: Управление версиями XML-словарей.

Будет интересно прочесть, спасибо.

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

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

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

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

ZS>А можно уточнить логическую связь между "средствами удаленного конфигурирования модулей" и "естественно, тут пришли к XML"? Собственно вопрос в том как именно XML позволяет конфигурировать удаленно. В зависимости от реализации возмоны различные варианты версионирования и обеспечения совместимости.

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