Формат ZML

> PROFIT же от формата ZML очевиден:

Прежде чем рассуждать о профите стоило бы, однако, сначала осилить XML и JSON и понять разницу между ними. А то ты не понимаешь первого и, очевидно, никогда не слышал о втором.

так и хочется сказать: yaml, json

Напомнило

http://www.linux.org.ru/forum/talks/5549159

> Зацените мой формат ZML (Zurin's Markup Language) как альтернативу XML.

конфиг довекота весь такой вот пушистый уже давно

1) компактность, меньше лишних символов => файлы занимают меньший размер

размер сильно неизменится

2) наглядность и читабельность для человека

у вас получается слияние свойств элемента и его детей

3) неограниченная расширяемость

кто мешает расширять xml

4) простота разбора

ещёодин паравоз разряда libxml ненужен

Черт, с геймдева набежали сюда..

А в чем разница? Оба формата используются для хранения структурированных данных. Как и ZML.

Рассмотрим тот же пример с конфигурацией.

На XML ее можно записать так:

<sound>+</sound>
<music>-</music>
<screen>
  <width>640</width>
  <height>480</height>
  <bpp> 32</bpp>
  <doublebuffer>+</doublebuffer>
</screen>

А на JSON так:

{
  "sound" : true,
  "music" : false,
  "screen": {
    "width" : 640,
    "height" : 480,
    "bpp": 32,
    "doublebuffer": true
  }
}

Как видно, в обоих случаях получается длиннее и труднее для разбора по сравнению с ZML.

<sound enabled="true"/>
<music enabled="false"/>
<screen width="640" height="480" bpp="32" doublebuffer="true"/>

Даже JSON заруливает.

у вас получается слияние свойств элемента и его детей

Не вижу проблемы.

object {
  property1 value1
  property2 value2
  ...
  propertyN valueN
  child {
    name "child1"
    ...
  }
  child {
    name "child2"
    ...
  }
  ...
  child {
    name "childN"
    ...
  }
}

ну вот ты говоришь-говоришь. А на деле --- ты изобрел недо-yaml. Осталось ссылки и мержи изобрести

<sound enabled="true"/><music enabled="false"/><screen width="640" height="480" bpp="32" doublebuffer="true"/>

110 символов, 48 лексем

sound + music - screen {width 640 height 480 bpp 32 doublebuffer +}

67 символов, 27 лексем

В формате ZML короче и проще.

  propertyN valueN
  child {
  ....

Глаза ломать переломать меремать и молотком по голове.

!это нечитабельно!

> Оба формата используются для хранения структурированных данных

XML это формат публикации, со своими свойствами. Там есть атрибуты, пространства имён, всякие xi:xinclude, а также XPath, XSLT и прочие радости. Т.е. это такая развитая технология со множеством спецификаций. А не просто формат для хранения структурированных данных.

JSON же это чистый формат данных, который, однако, лучше читать, чем ваш, проще писать, и который можно очень легко парсить (если забыть про безопасность) в JavaScript (плюс, сейчас браузеры предоставляют специальные функции).

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

Вот и вопрос: зачем вы придумали сей велосипед?

И что здесь нечитабельно? Трудно отличить значение от имени параметра? Поставь побольше пробелов. Например:

  propertyN   valueN
  child {
  ....

А XML что, читабельнее? Попробуй прочесть файлы в /etc/gconf

> Там есть атрибуты, пространства имён, всякие xi:xinclude, а также XPath, XSLT и прочие радости. Т.е. это такая развитая технология со множеством спецификаций.

Это все важно в сетевом программировании. В этой области я не претендую на замену XML. Тем не менее, XML часто используется просто для хранения данных. В этой области ZML является лучшим решением.

JSON же это чистый формат данных, который, однако, лучше читать, чем ваш, проще писать

Чем лучше и проще? Пока я вижу, что в JSON много синтаксического сахара.

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

Возьмем такой пример - разметка текста. Можно ли для этого использовать JSON? ZML и XML - можно.

> Это все важно в сетевом программировании.

Нет, это важно для публикации. И вообще, это важно как технология.

Тем не менее, XML часто используется просто для хранения данных.

Бороться с глупостью с помощью изобретения нового формата не очень разумно.

что в JSON много синтаксического сахара.

Отлично, все любят сахар.

Возьмем такой пример - разметка текста. Можно ли для этого

использовать JSON? ZML и XML - можно.

Для разметки текста лучше использовать reStructuredText или другие подобные форматы.

>Тем не менее, XML часто используется просто для хранения данных. В этой области ZML является лучшим решением.

Как без xslt и прочих xpath доставать данные с твоего формата? А есть удобное подобие DOM?

Пока я вижу, что в JSON много синтаксического сахара.

Главное в JSON то, что с ним действительно легко работать. Через js не нужно вообще париться, а в других языках есть простые либы. И весь сахар там как раз чтобы описать все распространённые структуры данных, которые известны.

>Возьмем такой пример - разметка текста. Можно ли для этого использовать JSON? ZML и XML - можно.
Ты предлагаешь использовать формат, в котором пробел, табуляция и перевод строки являются в большинстве случаев значимыми символами, для разметки текста? Для какого рода разметки это пригодно?

>Ты предлагаешь использовать формат, в котором пробел, табуляция и перевод строки являются в большинстве случаев значимыми символами, для разметки текста? Для какого рода разметки это пригодно?

Для специальной Z-разметки, которую в скором времени придумает автор. Её главной особенностью будет нескучность.

JSON = {object:{
  property1:value1,
  property2:value2,
   ...
  propertyN:valueN,
  
  child:[{
       name:"child1"
       ....
    },
    {
       name:"child2"
       ....
    },
    {
       name:"child3"
       ....
    }
  ]
}}
//  ------- JAVASCRIPT
object = JSON.decode(JSON);
document.writeln(object.object.property);
document.writeln(object.object.child[2].name);
//---------- PHP 
$object = json_decode($JSON)
echo $object->object->property1;
echo $object->object->child[1].name;

и Чем он луче того же JSON'a