![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Есть такой стандарт — DICOM. Очень обширный, старый (разрабатывался еще тогда, когда даже TCP/IP не было), очень большой. И проблемный.
В начале, проблемы начинаются у того, кто пытается его осознать :) Очень необычный текст стандарта, использует необычную терминологию, в которой еще надо разобраться. А еще это первый раз, когда я видел, чтобы OSI где-то использовалось.
А еще текст стандарта распространяется в очень неудобной форме — в виде десятка огромных pdf'ок без кросс-ссылок, приходится постоянно переключаться между открытыми окнами тормозящего Adobe Reader'а (грущу по kpdf, который нисколечки не тормозит и которым удобно пользоваться в отличие от адобовского поделия, но которого в винде нету).
Суть DICOM'а — в описании медицинской среды, состоящей из пациентов, врачей, больниц, обследований, снимков, оборудования, программ и взаимодействия всего этого. Для этого вводится собственный способ описания объектов и атрибутов (способ описания похож на бинаризованный XML), очень запутнный и коварный:) К этому добавляется вечная проблема кодировок (ну почему это так сложно? даже у ведущих производителей медицинского оборудования до сих проблемы с кодировками текста). И глючность и неполнота многих библиотек для работы с DICOM'ом.
Правда, ситуация немного улучшается.
В общем, ситуация довольно грустная. И в этом всем приходится разбираться.
Сегодня написал небольшой препроцессор, который берет xml-описание DICOM'а и генерит по нему соответствующие классы и код для их загрузки и сохранения. Работать стало приятнее :)
Пока писал, понял, как же неудобно кодогенерацию писать на языке без макросов. Пришлось написать аж 4 вещи: схему XML, сам XML, парсер, генератор кода. Когда в лиспе бы пришлось писать только определение макросов и собственно описание DICOM'а. И visual studio (по крайней мере, 2005-я) вообще коряво себя ведет с XML'ем. Дизайнер схемы невнятный и генерирует всякую чушь вместо ключей и связей, при редактировании XML студия иногда просто падает и неправильно обрабатывает схему (интересно было бы сравнивать студийный редактор с емаксовским nxml-mode).
Вообщем, сравнение XML vs s-expr смотрится довольно интересно. Одно дело, когда есть XML со схемой (которая на взгляд совершенно нечитаема), к которому нужная всякая обвязка в виде редакторов, валидаторов, парсеров и прочего, и другое дело, когда ничего этого не требуется, и можно писать просто формы языка, которые во время компиляции развернутся в нужные определения классов и код загрузки/сохранения. К тому же, генератор кода в лисповском случае будет гораздо более красивый и правильный и не нужно лишних шагов компиляции.
В начале, проблемы начинаются у того, кто пытается его осознать :) Очень необычный текст стандарта, использует необычную терминологию, в которой еще надо разобраться. А еще это первый раз, когда я видел, чтобы OSI где-то использовалось.
А еще текст стандарта распространяется в очень неудобной форме — в виде десятка огромных pdf'ок без кросс-ссылок, приходится постоянно переключаться между открытыми окнами тормозящего Adobe Reader'а (грущу по kpdf, который нисколечки не тормозит и которым удобно пользоваться в отличие от адобовского поделия, но которого в винде нету).
Суть DICOM'а — в описании медицинской среды, состоящей из пациентов, врачей, больниц, обследований, снимков, оборудования, программ и взаимодействия всего этого. Для этого вводится собственный способ описания объектов и атрибутов (способ описания похож на бинаризованный XML), очень запутнный и коварный:) К этому добавляется вечная проблема кодировок (ну почему это так сложно? даже у ведущих производителей медицинского оборудования до сих проблемы с кодировками текста). И глючность и неполнота многих библиотек для работы с DICOM'ом.
Правда, ситуация немного улучшается.
В общем, ситуация довольно грустная. И в этом всем приходится разбираться.
Сегодня написал небольшой препроцессор, который берет xml-описание DICOM'а и генерит по нему соответствующие классы и код для их загрузки и сохранения. Работать стало приятнее :)
Пока писал, понял, как же неудобно кодогенерацию писать на языке без макросов. Пришлось написать аж 4 вещи: схему XML, сам XML, парсер, генератор кода. Когда в лиспе бы пришлось писать только определение макросов и собственно описание DICOM'а. И visual studio (по крайней мере, 2005-я) вообще коряво себя ведет с XML'ем. Дизайнер схемы невнятный и генерирует всякую чушь вместо ключей и связей, при редактировании XML студия иногда просто падает и неправильно обрабатывает схему (интересно было бы сравнивать студийный редактор с емаксовским nxml-mode).
Вообщем, сравнение XML vs s-expr смотрится довольно интересно. Одно дело, когда есть XML со схемой (которая на взгляд совершенно нечитаема), к которому нужная всякая обвязка в виде редакторов, валидаторов, парсеров и прочего, и другое дело, когда ничего этого не требуется, и можно писать просто формы языка, которые во время компиляции развернутся в нужные определения классов и код загрузки/сохранения. К тому же, генератор кода в лисповском случае будет гораздо более красивый и правильный и не нужно лишних шагов компиляции.
