Такое может сказать только человек не видящий разницы между
2 + 2
и
“2” + “2”
между
“значние;зачение”
и
{значение; значение}
Будете мне регулярки предлагать чтобы их распарсить? История информатики и первый семестр структур данных прошел мимо вас, я понял.
d1g, следующее ваше предположение по отношению к окружающим, об уровне образования, уровне владения регулярными выражениями и необходимости их использования, обернется баном. dkiselev
Я так стар, что я историю если и не творил, то наблюдал и участвовал, а не изучал на первом курсе.
Ваши картинки различаются разделителями.
Новая схема может быть сколь угодно правильной и замечательной, но если он неоправданно сложнее, чем старая и ее нельзя объяснить пользователям, то она бесполезна.
Главный вопрос: Какие задачи можно решить, которые нельзя решить на старой схеме?
Указать несколько значений у смыслового ключа чтобы не нужно было парсить ключ или значение абсолютно всем пользователям, а не только тем которым нужны конкретные значения.
Те, кто парсил до этого, будут парсить после этого.
Те кто не хотят парсить ничего (>80% пользователей! сюрприз!), получают возможность используя <простые смысловые ключи>=yes либо <простые смысловые ключи>=<одно конкретное значение> делать запросы к БД без перебегания к парсингу чего-либо или регулярных выражений.
Вы же упёрлись на первом пункте и считаете что преимуществ для других не существует вообще.
После того как введём вложенные массивы и множества не нужно парсить ничего не будет никому. Перевод смысла в ключ упростит задачу перехода. Раз вы такой старый, преимущества сериализации-десериализации вместо ручного парсинга ключей и значений каждым разработчиком каждый новый раз объяснять вам не буду.
Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?
Мы таки наконец обретем поддержку целостности границ?
Или просто получим в чем-то более стройный код, на что пользователю глубоко наплевать. Скорее наоборот, если он теги пишет ручками в JOSM /Potlach 1, то ему только хуже.
То, что вы не понимаете преимущества сериализации и отсутствие этапа парсинга для пользователей это не уход от ответа. Это ваша упёртость на обязательности парсинга для всех. Вам ответили в 50 раз, вы опять сводите всё к парсингу своему.
Опять скажу- достоинств схемы может быть далеко не достаточно, если эти достоинства ничего не дают нового. Так что сторонники могут как угодно нахваливать схему, но ничего не говорить о достоинствах ее введения взамен имеющейся.
Если я не могу ничего от введения этой схему добавить в конечный продукт, то зачел ломать уже работающее?
Да мало ли кто чего хочет, ты хочешь ты и придумывай как фильтровать такие объекты, хочешь - регулярки пиши, да хоть AI. С чего вдруг кто-то твои проблемы будет решать, да к томуже сформулированные в столь претенциозной манере.
Можешь посмотреть в онтологии что значит претенциозность.
Может раз так, то закрыть тему? Раз задача поиска консенсуса больше не стоит?
Тот текст, который был, имел, на мой взгляд, здравую основу – не лепить множественные значения в основные теги, т.е. туда, где множественность вовсе не предполагается. Потому что классификация задумывалась как однозначная.
Это могло бы найти понимание в сообществе.
Теперь же, как я понимаю, предлагается сделать глобальную(т.е. по всей планете) замену схем тегирования с xxx=yyy на xxx:yyy=yes с поддержкой множественности.
Это совсем другая тема.
По моему в условиях лицензии OSM прямо указано, что сервер предоставляет открытые данные, но не сервис обработки запросов планетарного масштаба. В overpass API тоже есть нечто схожее. Поэтому если кто-то парсит сложные value по всей планете - он делает это при импорте в свою собственную базу. Например Mapsurfer.NET и любой другой рендер.