кстати, пример не сильно абстрактный. лично имел дело с двумя мото-конторами, одна из которых продаёт байки, экипировку и ремонтирует мото, плюс принимает байки на комиссионную продажу, вторая - продаёт мотаки, экип плюс услуги по ремонту и зимнему хранения мотоциклов.
при этом у торгового зала и ремонтной зоны разные телефоны и график работы.
при этом обе сильно отличаются от конторы-дилера, барыжащего новыми “ямахами”: мото, квадро, снегоходы, лодочные моторы.
Совсем упоролись. Json же! Несколько значений в квадратных скобках. Дикты и списки. Парсится на всех языках программирования. Определен ескейпинг. Стандартен чуть более чем полностью. Бросайте свои велосипеды. Джсон онли. Ну yaml в крайнем случае. Он лучше, но труднее валидируется и сложнее сам по себе.
А еще в постгресе знатная оптимизация и индексация джсона по полям плюс компактное хранение. Смекаете? Если внутри хранить именно так - Мегапрофит. Количество записей в бд резко сократится за счет денормализации.
Автор 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-кун, будем иметь в виду.
ваши аргументы блеск, огонь и кладезь мудрости, о юный интернет-воин.
ваши манеры теплы и прельстивы, оставайтесь на линии, сие весьма важно для нас.
Моё (если условиться, что всё - рабочие маркеры, а комментарии должны предваряться “/”):
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:
если маркер стоит “последним”, то нужно обработать все свойства=значения.
требуется знать какие из свойств=значений главные, а какие - нет
В нормальных онтологиях специально выделяют “понятие” и специальный синтаксис для него (хештег/двойной хештег) чтобы можно было
быстрее отличить его от свойства=значения
отличить его без знания предметной области
Т.е. это только вы знаете что building - основной, если у вас по тексту (обозначению) это не ясно, то значит этой информации недостаточно чтобы извлечь знания.
Напротив, если условится обозначать основые теги как ##building то будет сразу ясно что это “понятие”, а не “атрибут”.
Для быстроты парсинга хештеги должны быть в начале структуры. Т.е. получается чтобы узнать что у здания есть крыша придётся обрабатывать свойста building. Иногда имеет смысл продублировать информацию в хештегах для более быстрой обработки (быстрых запросов, специальных парсеров):
#building
#building:with:roof
/...
В принципе, метки building:with:roof не обязательны. И такие понятия можно добавить в базу в неявном виде или при обработке запроса.
Мне лично сомнительно преимущество выделения основных тэгов. Самоописательными они от этого не становятся.
Если вы получили объект с описанием
#вигвам
height=10
и не знаете, что такое “вигвам”, вам # не поможет. А высоту 10 метров можно бы и распарсить.
Чё-та мне кажется не надо опитимизировать синтаксис ради быстроты парсинга. Попахивает premature optimization, которая root of all evil.
Рекомендовать их ставить первыми - можно.
И не забываем, что их может быть больше одного, если объект является смесью сущностей с (всеми) общими свойствами.
речь не об этом. Знаний нет, зато вам не нужно угадывать что главное:
height=
вигвам=
Прямо сейчас можно наблюдать это в type=.
Вы точно также не знаете что такое height, вигвам - но можете на основе #вигвам отфильтровывать. непонятные хештеги могут сломать вашу программу
Как тогда быть с этим допущением в синтаксе: Глобальная пара { } подразумевается.
Т.е. глобальные пара всегда одна, но зачем если мы описываем двойственные объекты?
А если не требовать, а просто рекомендовать, то парсинг усложняется, причём настолько что этот формат будет не надстройкой на xml, а самостоятельным. В xml атрибуты всегда вначале не просто так:
Если все свойства одинаковые у двух сущностей, смешанных в один объект, нет смысла их разделять, дублируя все свойства.
Например, магазин + мастерская, с одним временем работы и т.д.
Конечно, самостоятельным. Текст с хэштэгами и { } единым куском - должен быть основным представлением описания свойств объекта.
XML строго иерархичен (если не начинать мудрить со ссылками).
ИМХО, объекты на карте мира слишком разнообразны, чтобы их описания укладывались в строго иерархичную структуру данных.
Моё предложение: вместо перечня tag-ом - описание в виде одного многострочного блока текста с хэштегами. Если основной формат данных остаётся XML - то многострочный блок как-то должен быть завёрнут, чтобы хранится внутри XML. Например, через 
 так:
Парсить и интерпретировать - в зависимости от решаемой задачи. Если задача найти объекты определённого вида - ищем в блоке маркеры, которым этот вид объектов обозначается. Если задача отрендерить каждый объект - парсим построчно и сверяемся с перечнем понятных для рендера маркеров.
Я уже два раза писал, что считаю иерархичную XML структуру не подходящей для описания свойств объектов. Геометрия может оставаться в XML, описание - не должно.
Я не понимаю вопроса.
Вы сами ввели “<описание элемента в osm>” и мне задаёте про него вопросы.
Я привёл пример как я вижу описание объекта.
А почему CDATA секции или текстовые элементы не подходят? Вы же не только простой текст в комментарии превращаете, но всё описание получается закодированным.
В каком-то смысле это хуже сейчашних <tag: их нельзя пользователю напрямую редактировать. Ваш формат не текстовый, он полу-бинарный, понимаете?
Понял, мы совсем о разных вещах говорим тогда. Я понимаю ваш синтаксис как xml с текстом-комментариями в xml.
