prev
next
ru.ftn.develop
FromSerguei E. Leontiev0:0/0.0Date Write2013-05-09 15:58:22
ToMithgol the Webmaster0:0/0.0Date Arrived2013-05-09 17:00:02
SubjRe: Способ доступа к эхолисту
Attr
From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Поздравляю всех с праздником!

Привет Сергей,

От вт, 07 май 2013 17:26:58 в fido7.ru.ftn.develop ты писал:

Ясное дело, тому кто любит JavaScript, JSON (JavaScript Object
Notation) должен нравиться.

>>> Аргументы в пользу JSON я привёл в том письме, на которое ты отвечаешь.
>>> А каковы аргументы в пользу XML, окромя 'лично мне больше нравится'?
SEL>> При использовании XML можно использовать принятую в русском ФИДО
SEL>> кодировку текста, в то время, как при использовании JSON, согласно RFC
SEL>> 4627, обязательно использование UTF-8/16/32, это во-первых.
Использование
SEL>> XML может быть более экономным, чем JSON, в силу накладных расходов
SEL>> кодирования русских букв в UTF-8 (UTF-16/32 будет иметь заведомо больший
SEL>> размер), это во-вторых.
MtW> Это наблюдение совершенно справедливо, однако оно может быть легко
преодолено.
MtW> Даже двумя способами.
MtW> Первый способ заключается в том, чтобы объявить допустимым употребление в
Фидо
MtW> однозначного преобразования в CP866. При условии, конечно, что в JSON ...

С экранирующими символами и последовательностями будут
трудности. И какой смысл тогда называть это "JSON-Фидо"? Ведь
всё равно стандартные средства работы с JSON окажутся
неприменимы. CSV, а тем более XML, куда как лучше применим к
CP866.

MtW> Второй способ заключается в том, чтобы последовать примеру Интернета и
целого
MtW> ряда операционных систем, перейдя на Unicode, причём именно в форме UTF-8:
её

А как же пресловутый байт "H" 0x8D? Для UTF-8 этот байт будет
порождаться очень важной буквой "э", чем её заменять прикажете?
Всего же таких букв 3*2^15, но я на них не смотрел :)

В UTF-16 число возможных таких букв несколько меньше: 248 + 256
+ 2*2^12. Современных русских букв среди них, вроде бы, нет,
есть диакритические знаки (используемые для ЙЁйё - не задеты) и
расширенная кириллица.

Вот у UTF-7 (RFC 2152) таких символов нет, но есть проблемы с
"+-", или UTF-9 (RFC 4042) попробовать :)

А если серьёзно, то русское ФИДО могло начаться с Юникода,
однако, сложилось использование альтернативной кодировки по ГОСТ
19768-87. Отмечу, что даже не КОИ-8 - основной кодировки по ГОСТ
19768-87, широко используемой в сетях UUCP в 80-х, а именно
CP866. Почему так вышло тогда, и какие основания к тому, что
сейчас выйдет иначе?

SEL>> Большему количеству людей известна аббревиатура XML, известность JSON
SEL>> несколько ниже, это в-третьих.
MtW> Мне кажется, что этот аргумент в пользу XML не может перевесить те
аргументы
MtW> в пользу JSON, которые я привёл в одном из предыдущих писем.
MtW>> В JSON же можно записывать строки, числа, логические
MtW>> значения (true и false), неопределённое значение (null).

Яркий тому пример, это ж типы JavaScript (ECMA-262), которые не
обязательно имеют точное соответствие в других языках. Hапример,
в языке Java нет точного соответствия "числу", а в C на
некоторых машинах при некоторых условиях "числу" соответствует
"double", но вот нет точного соответствия "строкам". Что же до
"(null)", то здесь путаница практически неизбежна.

MtW>> В JSON также можно записывать два вида
MtW>> структур (объекты с именованными полями и массивы с
MtW>> перечислением элементов по порядку)

Эти "массивы" - массивы JavaScript, для C - это список объектов
произвольных типов.

MtW>> а второй (массивы) в XML реализуется гораздо менее
MtW>> экономно

Hу с экономностью вроде бы уже разобрались, XML при правильном
использовании (в кодировке CP866) для целей ФИДО заметно
экономнее.

MtW>> Уместно заметить, что эхолист по сути является массивом,
MtW>> так что это достоинство JSON весьма ценно.

"Эхолист", является документом, который содержит список в
терминах C/C++, т.е. список объектов одного типа, однако, JSON
не имеет возможности это выразить.

Заметим, что его содержимое, по сути, именно список
(последовательность, множество), а не массив, т.к. номер
элемента не имеет, ни логического, ни физического смысла. Смысл
имеют разделы.

SEL>> Hу и в-четвёртых, стандартная аргументация за использование XML
SEL>> (отделение структур данных от кода, самодокументируемость, возможность
SEL>> формальной проверки по схемам, XSLT...).
MtW> JSON также не содержит кода (а только данные)

Хм. А как же оператор eval(), который используют на страх всему
миру?

MtW> и допускает формальную проверку
MtW> по схемам (сайт http://json-schema.org/ содержит некоторые подробности
этого).

Люди работают, но до идеала ещё далеко (даже до XML ещё далеко).

MtW> Аргумент о самодокументируемости XML тебе придётся огласить поподробнее.

XML (eXtensible Markup Language), ясное дело предназначен для
XML-документов в том числе и долговременных, соответственно,
можно несложным способом явно выразить все аспекты: версию XML,
кодировку, схему документа с её описанием, пространство имён,
комментарии. А так же прочитать, "глазами".

JSON (JavaScript Object Notation), предназначался для передачи
объектов между частями одной программы. Соответственно, у него
этого нет.

MtW> XSLT не поддерживается JSONом, что и понятно; однако есть аналоги.

:) Ага, ага, пишем NNN-сторк на JavaScript и все дела :)

А "эхолист" это всё таки документ, может иметь несколько
представлений и т.п. А так как, кроме того, использование XML
проще использования JSON и не требует смены кодировки или
перехода к "бинарному" представлению, то имеет смысл именно его
использовать, на мой непросвещённый взгляд.

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru <http://www.cryptopro.ru>
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)