AXON — это нотация для сериализованного представления объектов, документов и данных в текстовой форме. Она объединяет в себе простоту JSON, расширяемость XML и удобочитаемость YAML.
Есть проект pyaxon на python, с которым можно "поиграться". Впрочем, он создавался таким образом, чтобы не сильно уступать по скорости с модулем json. Поэтому он может сгодиться и для реальных дел.
Зачем AXON?
AXON появился как попытка справиться с недостатками или неудобствами JSON и XML, но сохранить при этом их достоинства и возможности, дополнительно добавив удобочитаемость, присущую YAML.
AXON содержит "улучшенный" вариант JSON
1. JSON имеет два неудобства:
- имена атрибутов/ключей, которые являются идентификаторами приходится заключать в кавычки;
- легко забыть запятую в случае вставки новой пары ключ: значение.
AXON устраняет эти неудобства следующим образом:
- можно не заключать в кавычки имена, которые являются идентификаторами;
- совершенно опускаются разделительные запятые, используются только пробельные символы для разделения элементов.
В результате получается более компактное представление и удобство восприятия при форматировании.
Для сравнения:
JSON
{ "name": "Alex",
"birth": "1979-12-25",
"email": "mail@example.com"}
[ "Alex"
"1979-12-25"
"mail@example.com"]AXON
{ name: "Alex"
birth: ^1979-12-25
email: "mail@example.com"}
[ "Alex"
^1979-12-25
"mail@example.com"]2. В JSON не гарантируется, что после загрузки
{ "name": "Alex",
"birth": "1979-12-25",
"email": "mail@example.com"}порядок ключей/атрибутов сохранится.
В AXON констатируется, что
{ name: "Alex"
birth: ^1979-12-25
email: "mail@example.com"}преобразуется в mapping без сохранения порядка ключей.
В то же время констатируется, что
[ name: "Alex"
birth: ^1979-12-25
email: "mail@example.com"]преобразуется в mapping с сохранением порядка ключей.
3. AXON поддерживает синтаксиc для представления даты и времени в ISO-подобном формате:
- даты
^2010-12-31
- времени
^12:30
^12:30:15
^12:30+03:00
^12:30:15-04:30- даты и времени
^2010-12-31T12:30
^2010-12-31T12:30:05.0125
^2010-12-31T12:30+04:00
^2010-12-31T12:30:05.0123-04:00а также для представления десятичных чисел:
1D 123456789D
3.14D 1.23e-6D4. AXON также позволяет определять метки неатомарных значений и использовать их в качестве внутренних ссылок. Это позволяет при необходимости не создавать копии многократно используемых неатомарных значений при сериализации/десериализации.
Например:
[ { prev: &a (2012-12-30 10:00)
next: &c (2012-01-01 12:00) }
{ prev: &b (2012-12-31 13:00)
next: *a }
{ prev: *c
next: *b } ]Метка имеет префикс & (&a &b &c), а ссылка имеет префикс * (*a *b *c).
Модель данных AXON содержит вариант модели Infoset XML в более компактной нотации
Рассмотрим иллюстративный пример XML представления структурированных данных:
<person>
<name>John Smith</name>
<age>25</age>
<address type="home">
<street>21 2nd Street</street>
<city>New York</city>
<state>NY</state>
</address>
<phone type="home">212-555-1234</phone>
</person>AXON реализует идею более простого синтаксиса для представления XML структурированных данных:
person {
name {"John Smith"}
age {25}
address {
type: "home"
street {"21 2nd Street"}
city {"New York"}
state {"NY"}
}
phone {type:"home" "212-555-1234"}
}Представление в формате AXON можно построить из формата XML за 5 шагов:
- Заменить
<tag>наtag { - Заменить
</tag>на} - Заменить
attr=valueнаattr: value - Текст внутри элементов заключить в двойные кавычки (
") - Удалить символ запятой (
,) или заменить его на один пробел
Результат такого преобразования структурно идентичен первоначальному XML документу. По-существу это синтаксически более компактная форма представления XML документа.
Для сравнения также приведем представление в AXON с форматированием сложных элементов без {} с использованием принципа одинакового отступа для подэлементов структуры:
person
name {"John Smith"}
age {25}
address
type: "home"
street {"21 2nd Street"}
city {"New York"}
state {"NY"}
phone
type: "home"
"212-555-1234"Это представление получается из предыдущего удалением всех символов { и }, а также ненужных пустых строк.
AXON расширяет возможности XML и JSON
В XML атрибуты могут иметь только простые значения, в AXON значением атрибута может любое значение (как и в JSON). Кроме того простые значения имеют тип (текст в формате unicode, число, десятичное число, дата и время, массив байтов в кодировке base64). AXON можно рассматривать как расширение JSON в том смысле, что объекты могут именованными, так же как и элементы XML являются именованными.
Например:
person
name: "John Smith"
age: 25
burn: 1975-10-21
locations: [
address
type: "home"
street: "21 2nd Street"
city: "New York"
state: "NY"
]
contacts: [
phone
type: "home"
"212-555-1234"
email
type: "personal"
"mail@example.com"
]В JSON есть одно неудобство, связанное с представлением нерегулярных структур, в которых существенен порядок частей. В таких структурах доступ к элементам осуществляется в результате последовательного поиска по имени, а не в результате "прямого" доступа по имени.
В качестве примера рассмотрим структурированный документ в формате XML:
<section title="Title">
<par style="normal">paragraph</par>
<enumerate style="enum">
<item>item text</item>
</enumerate>
<par style="normal">paragraph</par>
<itemize style="itemize">
<item>item text</item>
</itemize>
<par style="normal">paragraph</par>
</section>Непосредственно, без преобразования структуры этот документ не транслируется в JSON из-за важности порядка и повторяемости элементов. Один вариант трансляции, который эмулирует последовательность именованных элементов имеет вид:
{
"tag": "section",
"@": {"title": "Title"},
"*": [
{ "tag": "par",
"@": {"style":"normal", "text":"paragraph"}},
{ "tag":"enumerate",
"@": {"style": "enumerate"},
"*": [
{ "tag":"item",
"@": {"text":"item text"}}
]
},
{ "tag": "par", "@": {"style":"normal", "text":"paragraph"}},
{ "tag":"itemize",
"*": [
{ "tag":"item", "@": {"text":"item text"}}
]
},
{ "tag": "par", "@": {"style":"normal", "text":"paragraph"}}
]
}В AXON такие структуры транслируются "один в один":
section
title: "Title"
par
style: "normal"
"paragraph"
enumerate
style: "enum"
item { "item text" }
par
style: "normal"
"paragraph"
itemize
style: "itemize"
item { "Item text" }
par
style: "normal"
"paragraph"AXON поддерживает форматирование в стиле YAML
Привлекательной стороной YAML является формат представления в стиле wiki. AXON также поддерживает подобный стиль форматирования.
Например, для сравнения:
- форматирование без {} (
YAML-стиль)
person
name: "Alex"
age: 25- форматирование с {} и отступами (
C/JSON-стиль)
person {
name: "Alex"
age: 25}- компактный формат
person{name:"Alex" age:25}AXON может представлять серию объектов
Одно из ограничений JSON и XML связано с тем, что они представляют единственный корневой объект. Напротив, AXON представляет серию объектов или серию пар ключ:объект, которые можно загружать по одному. Например:
- серия объектов
{ name: "Alex"
age: 32 }
{ name: "Michael"
age: 28 }
{ name: "Nick"
age: 19 }- серия объектов с ключами
alex: {
message: "Hello"
datetime: ^2015-07-12T12:32:35
}
michael: {
message: "How are you"
datetime: ^2015-07-12T12:32:35
}
Комментарии (59)
thatsme
30.06.2016 20:44Вопросы
1. Можно-ли без кавычек использовать любой ключ? Например "$3ухлкйл Фр94нк, хи7 3"? Если да, то как это добавит удобочитаемости?
2. Чего именно я достигну используя AXON вместо JSON? Каковы преимущества, кроме представления структур в стиле python-way? Я не заметил в статье ответа на этот вопрос, т.к. описанные неудобства JSON надуманны.
intellimath
30.06.2016 22:21Без кавычек можно только идентификаторы.
Необходимость всегда использовать кавычки, как показал мне интернет — не совсем надуманные, впрочем единого мнения тут нет. Что касается запятых, то они, вообще говоря, не обязательны.
Для ответа на второй нужно было бы подробнее описать возможности библиотеки. Но для этого скорее всего получится еще одна статья.
Если кратко, то, например, можно отображать именованные элементы в объекты. Для этого регистрируется функция для его создания.
Пример приведен в ответе дляamaksr.
Suvitruf
30.06.2016 20:56+1В JSON не гарантируется, что после загрузки
Не верно. В описании json'а лишь говорится:
{ «name»: «Alex»,
«birth»: «1979-12-25»,
«email»: «mail@example.com»}
порядок ключей/атрибутов сохранится.An object is an unordered set of name/value pairs.
А порядок при маппинге зависит от библиотеки. В той же java, если мапить объект наLinkedHashMap, то порядок сохранится.intellimath
30.06.2016 21:32-1Но, например, в python для представления mapping's есть два типа: один гарантирует порядок, другой — нет. В JSON, если вы используете библиотеку на языке python, то вы уже не сможете в одних случаях использовать dict, а в других OrderedDict.
amaksr
30.06.2016 21:04Достоинства весьма сомнительные. Интереснее было бы, например, если бы новый формат позволял делать что-то более эффективно. Например экономить память за счет определения структуры объекта один раз для массива объектов. Или чтобы поддерживал разные типы значений, а не только число, сторку и дату. А так получается синтаксис ради синтаксиса.
intellimath
30.06.2016 21:51В статье затронут только аспект самой нотации как способа текстового представления объектов.
Разные типы объектов использовать можно. В библиотеке pyaxon есть возможность отображать классы на именованные структурные объекты. Например, можно отобразить
person { name: "Иванов" age: 30 }
на
namedtuple, определив:
text = """ person { name:"Иванов" age:30 } """ Person = namedtuple("Person", "name age") @axon.factory("person") def Person_factory(attrs, vals): return Person(**attrs) vals = axon.loads(text, mode="strict") print(vals[0])
Определение типа для всего списка AXON и библиотека
pyaxonпока еще не поддерживает.
AndreyRubankov
30.06.2016 21:09Документация показывает удобство YAML-like синтаксиса:
axon name: "AXON is eXtended Object Notation" atomic_values string: "abc абв ???" multiline_string: "one two three" date: ^2012-12-31
первый вопрос на котором себя словил: three" — почему тут есть кавычки? это какая-то специальная пометка?
не сразу заметил, что это конец строки.intellimath
30.06.2016 22:27-2Просто текст, заключенный в кавычки может состоять из нескольких строк.
AndreyRubankov
30.06.2016 22:55+3Да, я понял, но не сразу.
И если на такие грабли можно наступить на столь элементарном примере, то на более сложном это может вылиться в множество потраченных минут / часов на поиск проблемы.
Вложите более-менее сложный YAML документ, как многострочное поле в AXON документе, который в свою очередь представлен в виде YAML, это вполне валидный кейс:
— вы записываете в файл данные, пришедшие извне, в формате AXON в представлении YAML, для удобства чтения.
Шутки про вложение XML в JSON (или даже JSON в JSON) смешные, пока не столкнешься с ними в реальном проекте.intellimath
30.06.2016 23:04Ну может получиться нечто вроде этого:
.............. config: " option1: \"asdasdsadsd\" option2: \"erwrwetrter\" option3: \"vcnbnbmv\" " ............
Для этих целей преудсмотрена альтернатива:
.............. config: ` option1: "asdasdsadsd" option2: "erwrwetrter" option3: "vcnbnbmv" ` ............
Символ ` конечно нелегко заметить, может имеет смысл заменить его ```.
gearbox
30.06.2016 21:17+6имена атрибутов/ключей, которые являются идентификаторами приходится заключать в кавычки;
легко забыть запятую в случае вставки новой пары ключ: значение.
Это вы оригинальничаете или просто не в теме? Вторым пунктом ВСЕГДА идет отсутствие комментариев и не надо ничего придумывать. Запятую они могут забыть… Надо изучать матчасть перед началом разработки:
JSON, который можно комментировать
KTV. Новый JSON
JSON для любителей скобочек
Усложнённый упрощённый JSON
Universal Binary JSON — ещё один бинарный JSON
jsonex – упрощаем сложные клиент-серверные диалоги
JSON с комментариями (github, внизу смотреть список аналогичных проектов)
Tree — убийца JSON, XML, YAML и иже с ними — однозначно рекомендую комменты к прочтениюintellimath
30.06.2016 22:01Комментарии в AXON имеются в стиле python.
Претензию на оригинальность можно было бы принять, если бы AXON претендовал на оригинальность. Это эксперимент, возможно удачный, возможно не очень.
NeoCode
30.06.2016 23:28+2Надо бы подумать, прочитать все это на эту тему и разработать JSON 2.0 — с комментариями, с возможностью не ставить кавычки для простых типов (числа, идентификаторы) и возможно чего-то еще. Но именно JSON, а не новый формат.
Что касается YAML'а, то мне как-то не нравятся пробело-табо-зависимые форматы. С другой стороны, yaml уже есть, зачем пытаться совместить все сразу?intellimath
30.06.2016 23:55В первоначальной версии форматирования в стиле YAML отсутствовало. Оно было добавлено как возможность.
Принципиальное отличие от JSON в том, что AXON имеет именованные элементы.
Что касается JSON 2.0, то он принципиально привязан в синтаксису javascript. И скорее всего, придется ждать пока все перечисленное не появится в формате JSON как части javascript.
GerrAlt
10.11.2016 16:47+1Допустим, что луч света будет многократно отражаться между этими двумя зеркалами. Движение луча света будет происходить по вертикальной оси, при каждом отражении отмеряя время как метроном.
судя по упоминанию вертикальной оси предполагается ортогональность направления движения луча и плоскости зеркалintellimath
03.07.2016 10:58+1
AndreyRubankov
30.06.2016 21:24JSON имеет два неудобства:
- имена атрибутов/ключей, которые являются идентификаторами приходится заключать в кавычки;
- легко забыть запятую в случае вставки новой пары ключ: значение.
AXON устраняет эти неудобства следующим образом:
- можно не заключать в кавычки имена, которые являются идентификаторами;
- совершенно опускаются разделительные запятые, используются только пробельные символы для разделения элементов.
JSON имеет куда более неприятные особенности, чем приведенные в статье.
Как вариант, в JSON необходимо каждый раз указывать все имена полей в массиве однотипных объектов. Из-за этого объем json документа существенно увеличивается.
Убрать кавычки, если ключ имеет вид идентификатора — это существенное усложнение парсера, которое позволит сэкономить 20 символов для строки длинной в 300 символов.
К тому же из документации не понятно, можно ли кавычку " или какой-то спец.символ использовать как Ключ, как вариант для конфигурации автозамены.Delphinum
30.06.2016 21:27Как вариант, в JSON необходимо каждый раз указывать все имена полей в массиве однотипных объектов
Зачем?AndreyRubankov
30.06.2016 21:33Предположим у нас массив оценок за тест:
[{"name": "A", "score": 90}, {"name": "B", "score": 80}, {"name": "C", "score": 70}, {"name": "D", "score": 60}]
Можно обойти, задав жесткий контракт:
[["A", 90], ["B", 80], ["C", 70], ["D", 60]]
Но семантика уже не та.Delphinum
30.06.2016 21:37+1Но семантика уже не та
А как на счет:
{ "type": ["name", "scope"], "collection": [["A", 90], ["B", 80], ["C", 70], ["D", 60]] }AndreyRubankov
30.06.2016 21:52Этот вариант намного лучше!
Но теперь нужно писать encoder / decoder для этого формата во всех частях системы на всех языках, которые в нашей системе будут и нам очень повезет, если у нас будет язык со слабой типизацией.
Но это уже трейдоф: решили проблему объема данных, заплатили написанием кастомного парсера.intellimath
30.06.2016 22:52А можно так:
data { type: ("name" "scope") ("A" 90) ("B" 80) ("C" 70) ("D" 60) }
@axon.factory("data") def data_factory(attrs, vals): name, scope = attrs["type"] tp = get_type_factory(name, scope) return [tp(args) for args in vals]AndreyRubankov
30.06.2016 23:29Это ни чем не лучше приведенного выше примера JSON. Недостатки те же.
Кстати, семантически ваш пример, это Node, Dict, Set или что?intellimath
01.07.2016 00:02Согласен, что не лучше. Но использование именованного элемента дает идиоматический способ преобразования в объектное представление при наличии зарегистрированных порождающих функций.
Без отображения — это Node. С отображением — список объектов типа, который вернет get_type_factory.
intellimath
30.06.2016 22:40Строка из одной кавычки будет записана как "\""
Для массива из однотипных объектов можно было бы предложить, например, такое решение:
persons { {name: "Иванов" age: 30} {name: "Сидоров" age:33} }
@axon.factory("persons") def persons_factory(attrs, vals): return [Person(**val) for val in vals] vals = axon.loads(text, mode="strict") print(vals)
В результате получим
[[Person(name='Иванов', age=30), Person(name='Сидоров', age=33)]]
Deosis
01.07.2016 08:17В вашем примере названия полей все равно повторяются и занимают в 2 раза больше места чем сами данные.
intellimath
01.07.2016 08:22Согласен, что в этом примере это так. Если нужно без полей, то тогда возможен следующий вариант:
persons { ("Иванов" 30) ("Сидоров" 33) }
@axon.factory("persons") def persons_factory(attrs, vals): return [Person(*val) for val in vals] vals = axon.loads(text, mode="strict") print(vals)
gearbox
30.06.2016 21:27В JSON не гарантируется, что после загрузки
{ "name": "Alex",
"birth": "1979-12-25",
"email": "mail@example.com"}
порядок ключей/атрибутов сохранится.
В AXON констатируется, что
[ name: "Alex"
birth: ^1979-12-25
email: "mail@example.com"]
преобразуется в mapping с сохранением порядка ключей.
В JSON тоже можно массивы.
intellimath
30.06.2016 21:54-1[ name: "Alex" birth: ^1979-12-25 email: "mail@example.com"]
это не массив
AndreyRubankov
30.06.2016 22:09В AXON — да, это не массив, но проблему порядка ключей и значений в JSON можно решить через массив:
[ ["name", "Alex"], ["birth", "1979-12-25"], ["email", "mail@example.com"] ]
или:
[ {"name": "Alex"}, {"birth": "1979-12-25"}, {"email": "mail@example.com"} ]
в зависимости от предпочтений, технических возможностей и ограничений.
При этом использовать стандарт разметки, которы поддерживается во всех языках и давно отлажен и отлично работает.intellimath
30.06.2016 22:44-1Да можно, но при этом усложнится обработка такого массива.
В данном случае просто есть встроенная возможность получить словарь (ordered dict).
AndreyRubankov
30.06.2016 23:46Смею не согласиться. Такой функционал крайне редко нужен (далеко не в каждом языке есть ordered dict). Но если он потребуется, то дополнительные 5-10 строк кода для обертки над таким массивом будет с головою достаточно.
intellimath
01.07.2016 00:06-1Кстати нотация для ordered dict была добавлена по предложению одного пользователя. Для него это было важно.
alexkunin
01.07.2016 04:22+1Принимать решения об изменении формата общего назначения на основании отзыва или предложения одного пользователя — не очень хорошо. Кто-то поленился написать пару строк обработчика, кто-то не сумел, у кого-то нелюбовь к скобочкам, кто-то очарован питонским индентом — это все мелочи и субъективщина. Даже репорты о принципиальной невозможности сделать что-то (без удобоваримого воркэраунда) нужно рассматривать очень осторожно.
Это была попытка конструктивной критики, честно. Возможно, это был очень убедительный или влиятельный пользователь, или даже заказчик, или у вас была какая-то еще причина принять его предложение. Но без дополнительной информации все это выглядит как добавление фичи ради фичи.
О, да, это ведь тоже было мнение пользователя (пусть я и не пользуюсь аксоном реально), так что его тоже стоит воспринимать весьма скептически. ;)intellimath
01.07.2016 08:27В данном случае причина была в следующем: в сообщении при декодировании в одних местах нужен был dict, а в других — ordered dict (благо в python он есть). К моему удивлению он хранил конфигурацию для своей системы.
IvanPanfilov
01.07.2016 06:48+2http://imgs.xkcd.com/comics/standards.png
synedra
01.07.2016 08:46Зашёл в комменты только чтобы залить эту картинку, но вы меня опередили. Действительно, новые форматы — это симпатично, но решают же не только качества формата, но и его популярность. Никто не станет рисковать обратной несовместимостью работающего JSON API ради того, чтобы сэкономить сотню байт на кавычках с запятыми и избежать строительства костылей вокруг порядка ключей. И более того, выбирая между двумя серверами, которые делают примерно одно и тоже, лично я скорее предпочту тот, который не заставляет меня думать, а есть ли для моего любимого языка обработчик его формата данных.
Да, это инерция и ретроградство. Но даже если AXON однозначно не хуже JSON в любом возможном случае, вокруг второго-то уже есть инфраструктура и он свои задачи решает. За очень редким исключением замена JSON на что бы то ни было ещё будет починкой несломанного, ИМХО.intellimath
01.07.2016 09:06-1Никто не ожидает того, что AXON или любой другой формат сразу заменит JSON. Вспомните сколько прошло времени для того, чтобы JSON API стали включать наравне с XML API.
Чтобы быть более точным, если AXON и стоит использовать, то только в новых проектах.
ardente
01.07.2016 09:31+1Это не инерция, скорее следование принципу «не надо чинить то, что не сломано». Протоколу tcp/ip сколько лет уже, а не меняют.
dolphin4ik
01.07.2016 09:56+1Я так понимаю табуляции и отступы важны?
intellimath
01.07.2016 11:55Важны, если используется стиль форматирования для именованного элемента в духе YAML. Например:
person { name:"Иванов" age:30 }
здесь не важны, но для
person name: "Иванов" age: 30
важны.
Для списков, словарей, множества, кортежа — не важны, так как для них не предусмотрен стиль форматирования в стиле YAML.
dolphin4ik
01.07.2016 18:48Как по мне так это большой провал. Не могу не задумываясь передавать Axon в виде текста. JSON обыгрывает в этом случае
saksmt
01.07.2016 10:48А в чём конкретный профит?
Я к тому, что для конфигов есть yaml и HOCON (и насколько я вижу axon — heavily inspired by HOCON), а если для трансфера объектов, то читаемость отходит на второй план и на первое место выходит объём данных и производительность парсеров + возможность потокового разбора, о чём в статье ни единого слова нет.
intellimath
01.07.2016 12:15AXON не имеет отношения к HOCON.
Для трансфера в AXON не нужно использовать форматирование с табами и отступами. Тогда получится компактная форма.
Статья увы неполная.
intellimath
01.07.2016 12:20-1По поводу профита. AXON главным образом создавался для текстовой сериализации. Писать конфиги можно, но это не имелось ввиду, так как считаю что YAML вполне подходит для этого.
saksmt
04.07.2016 21:18Раз для сериализации, то можно немного статистики по скорости сериализации/десериализации + средний объём данных в сравнении с JSON и MessagePack (понимаю, что последний — бинарный формат, но AXON тоже так умеет, так что было бы интересно посмотреть) + вы так и не ответили на вопрос про потоковую сериализацию/десериализацию.
intellimath
04.07.2016 22:06AXON это текстовая нотация для представления данных (текст в формате unicode). Сообщение AXON представляет последовательность значений или последовательность пар
ключ:значение. Поэтому читать из потока и писать в поток каждое значение или пару ключ: значение можно итеративно в отличие от JSON.
Есть несколько тестов сравнения скорости загрузки/дампа с JSON. Дамп отстает от JSON в среднем на 10-15%, загрузка в среднем на 20-50% (по моим наблюдениям эти цифры можно немного уменьшить). Естественно, что скорость загрузки/дампа в случае JSON будет быстрее, так он имеет более простую структуру. Однако при загрузке/дампе очень больших последовательностей данных AXON выигрывает из-за того, что не нужно сначала строить всю последовательность в памяти. Сравнение производительности проводилось для реализации pyaxon и модуля
jsonиз стандартной библиотеки версии 3.5. Для более ранних версий python (2.7 — 3.4) процентные величины меньше (в python 3.5. производительность json заметно улучшена).
Сравнение с MessagePack не производилось, так как из общих соображений ясно, что производительность для сообщений, содержащих числовые данные будут кодироваться и декодироваться существенно быстрее в MessagePack, посколько AXON является текстовым форматом. Так что сравнивать имеет смысл только сообщения, содержащие структурированный текст.
Bozaro
01.07.2016 11:29+1Совершенно не понял: чем AXON лучше, чем YAML?
Как предполагается решать определение типов объектов (в JSON — доп. поле, в YAML — тэги, в XML — пространства имен, в AXON — ?)?intellimath
01.07.2016 12:06-1В AXON как в XML можно использовать элементы с именами/тегами.
В библиотеке
pyaxonиспользуется механизм регистрации порождающей функции по имени элемента.
Для примера см. комментарий
intellimath
05.07.2016 10:17Я не ответил на вопрос: чем AXON лучше, чем YAML.
AXON создавался как нотация для текстового представления объектов/данных, который бы, по возможности, объединил достоинства JSON, XML и YAML, а также по возможности избежал их недостатков. Если не всех, то основных.
Поэтому говорить, что YAML хуже чем AXON или наоборот некорректно.
TyVik
Возможно я невнимательно читал, а можно ли запихнуть AXON в AXON?
AndreyRubankov
Можно еще добавить пару извращений:
— можно ли запихнуть XML в AXON?
— можно ли запихнуть JSON в AXON?
У нас системы общаются на базе AXON и нам нужно прокинуть в еще одну нашу систему XML (или JSON), который получили от пользователя.
intellimath
Да, можно.
intellimath
XML без пространств имен можно также по ходу преобразовать в AXON. Для этого достаточно прочитать его, например, при помощи etree или lxml.etree и вставить получившийся объект с именем, скажем xml. Зарегистрировать reducer для типов XmlElement, XmlDocument, XmlAttribute. Затем во время dump-инга он преобразуется в представление в нотации AXON. Если зарегистрировать factory функциию для элемента xml, то после загрузки вв соответствующем месте будет XmlDocument.