Обсуждаем новые структуры данных API, избавляемся от строка=строка

Автор JSON истеричка и его мирок ограничен только языком JS. На JSON свет не сошёлся. Основной формат будет XML, как и всегда. Прежде чем вспоминать модные словечки (JSON, YAML, ОБОЖЕМОЙЯИЗОБРЁЛКАКРАБОТАЛИСПИСКИВЛИСПЕЩЕ45ЛЕТНАЗАД) зачем вы это говорите вообще?

Где DOM парсеры для JSON? Где стримящие парсеры для JSON?
Где в вашем JSON: CSS, XPATH? Как вы в вашем JSON делаете проверки элементов на что-то? Кто-то решил изобрести велосипед и решил что каждый разработчик должен писать код выборки на каждом языке?
Где в вашем JSON XSD? Вы хоть раз типизировали ваши структуры? Или парсить строки каждый день это мода на stackoverflow?
Предложите хоть одну вменяемую библиотеку для JSON. Хоть для одного языка. Вы libxml хоть раз видели?

Потому что в нём ничего и нет больше.

  • Ни опциональной типизации XSD
  • Ни гибких языков запросов XSLT, XPATH, CSS
  • Ни расширяемости в другие языки-стандарты (ответ на вопрос “да кому он нужен?”)
  • Ни нормальных библиотек для работы с ним (json.org не предлагать)

В JavaScript он более приятный чем в других языках. Меня тошнит от него в любом языке с нормальной типизацией (не JS).

(кротко) хорошо, о юный json-кун, будем иметь в виду.
ваши аргументы блеск, огонь и кладезь мудрости, о юный интернет-воин.
ваши манеры теплы и прельстивы, оставайтесь на линии, сие весьма важно для нас.

Ы? Really?

JSON:

Моё (если условиться, что всё - рабочие маркеры, а комментарии должны предваряться “/”):

  building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    roof
    shape: flat
    material: rubber
  }

Кавычек нет, запятых нет, при ошибке обычного синтаксиса в одной строке остальное не ломается

ИМХО, не надо умножать сущности.
Есть маркер, он может иметь значение, а может не иметь.
oneway - не главный тэг

Раз уж пошло активное обсуждение синтаксиса - публикую описание на оригинальный синтаксис для адресной книжки. Есть RFC-образная спецификация.
Поскольку адресная книжка ориентирована на то, что записать информацию важнее, чем её разметить, то там допустим простой текст, без разметки, а # служит разметкой.
Иерархии через { } там вообще нет, т.к. я посчитал, что строго группировать адресную информацию - дело глубоко безнадёжное.

Т.е. в таком упрощённом синтаксисе нужно понимать как 5 тегов-понятий и 3 атрибута у каждого из этих понятий?

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

Если же скобки убрать то будет неоднозначность: являются ли нижеследующие атрибутами свойствами понятия (building) или самостоятельными понятиями (type, levels, height). Одно другого не исключает, но в рамках свойств building и старой схемы я придерживаюсь мнения что “этажность” это таки свойство здания (building) и его нужно обрамлять скобочками.

Нет.
Всё, что находится внутри одной пары { } является описанием одной сущности. Аналогично с тем, что сейчас все тэги объекта в ОСМ являются описанием одной сущности.
Нет разницы между маркерами внутри одной пары { }, “ключевой” маркер может стоять первым, может последним.
Пара { } внутри другой является описанием подчинённой сущности, которая принадлежит внешней.
Глобальная пара { } подразумевается.

Вот это:

  building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    roof
    shape: flat
    material: rubber
  }

означает 2 сущности:
Основная: здание, публичное, 2 этажа, высотой 15 метров, из кирпича
Подчинённая сущность: крыша, плоская, из резины

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

  1. если маркер стоит “последним”, то нужно обработать все свойства=значения.
  2. требуется знать какие из свойств=значений главные, а какие - нет

В нормальных онтологиях специально выделяют “понятие” и специальный синтаксис для него (хештег/двойной хештег) чтобы можно было

  1. быстрее отличить его от свойства=значения
  2. отличить его без знания предметной области

Т.е. это только вы знаете что building - основной, если у вас по тексту (обозначению) это не ясно, то значит этой информации недостаточно чтобы извлечь знания.
Напротив, если условится обозначать основые теги как #building то будет сразу ясно что это “понятие”, а не “атрибут”.

понял, тогда с учётом этого, нужно сделать хотя бы так:

  #building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    #roof
    shape: flat
    material: rubber
  }

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


#building
#building:with:roof
/...

В принципе, метки building:with:roof не обязательны. И такие понятия можно добавить в базу в неявном виде или при обработке запроса.

PS. Давно не писал CSS, предок с прямым потомком:

object#building > #roof

можно было бы его ускорить до

object#building:with:roof

Мне лично сомнительно преимущество выделения основных тэгов. Самоописательными они от этого не становятся.
Если вы получили объект с описанием

#вигвам
height=10

и не знаете, что такое “вигвам”, вам # не поможет. А высоту 10 метров можно бы и распарсить.

Чё-та мне кажется не надо опитимизировать синтаксис ради быстроты парсинга. Попахивает premature optimization, которая root of all evil.
Рекомендовать их ставить первыми - можно.

И не забываем, что их может быть больше одного, если объект является смесью сущностей с (всеми) общими свойствами.

речь не об этом. Знаний нет, зато вам не нужно угадывать что главное:

  • height=
  • вигвам=

Прямо сейчас можно наблюдать это в type=.
Вы точно также не знаете что такое height, вигвам - но можете на основе #вигвам отфильтровывать. непонятные хештеги могут сломать вашу программу

Как тогда быть с этим допущением в синтаксе:
Глобальная пара { } подразумевается.

Т.е. глобальные пара всегда одна, но зачем если мы описываем двойственные объекты?

А если не требовать, а просто рекомендовать, то парсинг усложняется, причём настолько что этот формат будет не надстройкой на xml, а самостоятельным. В xml атрибуты всегда вначале не просто так:

Если все свойства одинаковые у двух сущностей, смешанных в один объект, нет смысла их разделять, дублируя все свойства.
Например, магазин + мастерская, с одним временем работы и т.д.

Конечно, самостоятельным. Текст с хэштэгами и { } единым куском - должен быть основным представлением описания свойств объекта.
XML строго иерархичен (если не начинать мудрить со ссылками).
ИМХО, объекты на карте мира слишком разнообразны, чтобы их описания укладывались в строго иерархичную структуру данных.

Есть смысл, это упростит обработку специализированных ключей. Если этим не злоупотреблять то ничего страшного я в этом не вижу.

Прямо сейчас в osm можно продублировать информацию об объекте мира, этим не злоупотребляют без надобности.

Технически это запретить в любом случае не получится без знания всех доменов в OSM, это займёт много лет такая задача.

Ну я собственно про это и спрашиваю - зачем корень один требовать:
Глобальная пара { } подразумевается.

<описание элемента в osm>
<суть class=“building”></суть>
<суть class=“#leisure”></суть>
</описание элемента в osm>

Для одного объекта ОСМ имелось ввиду.

Ну мне тогда не понятно как их считать, как парсить и интерпретировать, на примере xml это можно показать?

<описание элемента в osm>
   <суть class="#building">
      <height>3m</height>
   </суть>
   <суть class="...">
      ...
   </суть>
</описание элемента в osm>

upd: У <описание элемента в osm> есть какие-то общие свойства?

Например, сейчас в XML:

  <way id='36770486' timestamp='2012-08-06T20:36:37Z' uid='109327' user='OverQuantum' visible='true' version='3' changeset='12638603'>
    <nd ref='425868266' />
    <nd ref='427526277' />
    <tag k='bridge' v='yes' />
    <tag k='foot' v='yes' />
    <tag k='highway' v='path' />
    <tag k='layer' v='1' />
  </way>

Моё предложение: вместо перечня tag-ом - описание в виде одного многострочного блока текста с хэштегами. Если основной формат данных остаётся XML - то многострочный блок как-то должен быть завёрнут, чтобы хранится внутри XML. Например, через &#xD так:

  <way id='36770486' timestamp='2012-08-06T20:36:37Z' uid='109327' user='OverQuantum' visible='true' version='3' changeset='12638603'>
    <nd ref='425868266' />
    <nd ref='427526277' />
    <data k='#highway: path &#xD #bridge &#xD layer: 1' />
  </way>

Парсить и интерпретировать - в зависимости от решаемой задачи. Если задача найти объекты определённого вида - ищем в блоке маркеры, которым этот вид объектов обозначается. Если задача отрендерить каждый объект - парсим построчно и сверяемся с перечнем понятных для рендера маркеров.

Так нет же! Я предлагаю настоящий кусок xml пользователю, а не закодированный xml в параметр


<way старый
   <nd 
   <nd
   <tag
   <tag
   <описание элемента в osm
      <суть
      <суть
</way

Со временем от тегов откажемся (не будем использовать).

В вашем варианте получается обязательно k=’ декодировать прежде чем даже отфильтровать данные с #ufo.

Поэтому и вопрос: какие-то свойства у <описание элемента в osm> есть по моей схеме? Или это просто контейнер сутей?

Я уже два раза писал, что считаю иерархичную XML структуру не подходящей для описания свойств объектов. Геометрия может оставаться в XML, описание - не должно.

Я не понимаю вопроса.
Вы сами ввели “<описание элемента в osm>” и мне задаёте про него вопросы.
Я привёл пример как я вижу описание объекта.

А почему CDATA секции или текстовые элементы не подходят? Вы же не только простой текст в комментарии превращаете, но всё описание получается закодированным.

В каком-то смысле это хуже сейчашних <tag: их нельзя пользователю напрямую редактировать. Ваш формат не текстовый, он полу-бинарный, понимаете?

Понял, мы совсем о разных вещах говорим тогда. Я понимаю ваш синтаксис как xml с текстом-комментариями в xml.

Перенос строки является частью текста. То что его надо кодировать спец-символом внутри XML - проблема XML.

Допустим, а как тогда кодировать текст в первую очередь и ещё машинно читаемую информацию при этом иметь?

Текст отдельно, метаданные отдельно? Как тогда их связывать в визуальном редакторе?

Какой “текст в первую очередь”?
Названия - в значениях. Если надо записать пробел в значении, то обязательно обрамляем в {}, если без пробелов - {} не обязательны.
Комментарии к чему угодно - после / и до конца строки.


name: {улица Космонавтов}
max,speed: 40  /знак

“/знак” - комментарий, типа мапперу было влом разбираться как проставить источник инмформации об ограничении скорости.

Машиночитаемость отличная. Записная книжка на 200 000 знаков отлично парсится, валидируется, экспортируется, синхронизируется и т.д.