Кстати, в вашем развернутом вопросе о компактности содержится и ответ. Почему json победил... ну не победил конечно, но здорово потеснил xml на большей части поля боя? Не в последнюю очередь потому, что:
"Какое-то_число": 777,
значительно компактнее, и более удобочитаемо, чем:
Верно. Она не забыта, и даже deepseek на нее намекал. Но есть нюанс. Как я уже говорил, один из главных приоритетов - компактность, а одно из средств достижения этого приоритета - сокращение области определения. Проще говоря - неопределенные состояния запрещены. Тем не менее, вам спасибо за комментарий - очевидно, что это ограничение необходимо явно указать в нотации. И может быть вернуться к этому вопросу в дальнейшем.
Признаю ваш аргументы убедительными, что касается и принятия - это вопрос... Кстати, это и DeepSeek отметил - мол, не все понятно без документации. Относительно минуса, как NOT. Да, переход от математического контекста к логическому несколько неожидан, особенно если игреки не числа, а строки, к примеру. Но это сделано в угоду компактности, и, полагаю, этот скилл быстро усвоится.
Что касается остального... Намекаете на то, что нет приведения к единой ДНФ, КНФ? Думаю над этим.
Все верно, но... это только первая итерация. В сущности - это тот же json, но безусловно элегантнее. Смотрите. В действительности задачи данного проекта состоят в следующем:
Сократить формат условных выражений SQL-подобного синтаксиса. Проще говоря, любого, или почти любого выражения WHERE. Очевидное, но не единственное, решение - конвертация из существующих объектных форматов или форматов передачи данных - json, xml, xsd, yml и т.д. и т.п. Альтернатива - собственный формат, что и реализовано в предложенном вами решении. Я же остановился на json.
Сократить выбранный объектный формат до минимального за счет сокращения области определения. В данном случае формат json - он же вообще для всего. Предложенный вами формат sql.tree - это конкретная json-подобная реализация полного sql-запроса. Что, в сущности, и является тем самым сокращением области определения. Но... недостаточным. Потому что здесь речь идет о выражениях WHERE, как о самых проблемных в смысле компактности. А в вашем решении (как и в json) проблема компактности остается, просто из горизонтали переходит в вертикаль, транспонируется.
В любом случае, все это очень любопытно, позже я посмотрю повнимательнее. Спасибо.
Спасибо огромное за ваш комментарий, считаю, что с его появлением статья уже свою роль сыграла. Действительно, с функциями MIN и MAX мой промах. В свое оправдание замечу, что настрой был и остается опираться на чистый SQL: OR, AND, NOT, =, >, <. Потому что применение нотации может оказаться неожиданным, в т.ч и в области, где операторы <= не определены. Этим и объясняется отсутствие IN, а также некоторое дублирование синтаксиса. А наличие-таки BETWEEN, MAX и MIN - это дань лени и спешке. Что особенно любопытно, хотя и не неожиданно - DeepSeek ошибки с MAX пропустил. Работать со временем... откровенно говоря, я об этом не думал, но подумаю обязательно. В общем, спасибо вам еще раз.
Это немного не так работает. Автор ГОСТа - это почти всегда лидер рынка, и стандартом он как бы фиксирует свою позицию. Поэтому если ГОСТ меняется, тут два варианта - или лидер пытается укрепить свою позицию, с учетом новых реалий в технологиях, либо другой пытается перенять лидерство, или, по крайней мере, встать рядом.
А получает автор роялти или нет - я не знаю. Но даже если и так, не думаю, что это основной источник финансирования разработчиков. Основной источник - бюджет лидера отрасли.
А речь именно об оформлении. В противном случае, смешивать ЕСКД и СПДС было бы неразумно. А насчет нормоконтроля... Вы не напрасно слово употребили слово "поможет" в кавычках. Тут как повезет. Ну и насчет фетиша :)) Тут Вы правы, и именно поэтому в обзоре этого нет.
Ну и да... разве не бывает КД, где основная надпись заполнена исключительно одной фамилией, от первой до последней графы, включая "Утв." и "Н.контр." :)) Бывает :))
Дополню ответ. Знаете сколько стандартов числит Росстандарт в СПДС? Предположу, что нет. А я вам скажу - 112. А сколько действующих? 52, вполовину меньше. Более того, некоторые включены по 3-4 раза, например первый и главный - "Общие положения":
ГОСТ 21.001-93 (СССР, заменен)
ГОСТ Р 21.1001-2009 (РФ, отменен), обозначен с нарушением формата - 1001
ГОСТ 21.001-2013 (СНГ, утратил силу в РФ)
ГОСТ Р 21.001 (РФ, действует)
И так далее. В ЕСКД примерно такая же ситуация. Но это еще ничего, отменены, заменены, утратили силу. Есть же стандарты парные - национальный и межгосударственный, действуют оба, хотя тоже пару тройку раз перевернулись.
Я уже отвечал на похожий вопрос. Это не статья, а обзор, это раз. Второе - обзор рассчитан не на инженеров по стандартизации, и не на нормоконтролеров, а на проектировщиков, преимущественно на начинающих. Третье - обзор предваряет каталоги ЕСКД, СПДС и ЕСТД, которые есть в расширенной статье на канале (указан в конце обзора). И четвертое - не так уж и просто ищется, повторю - официальные стандарты платные. Неофициальные зачастую тоже платные. И конечно у профи есть все на жестком диске, ну так они этот обзор и читать не станут. разве что из любопытства.
Ну и вообще... о чем - все написано в самом обзоре, зачем - я пояснил.
Да, по второй части что-то в этом роде. А вот с первой сложнее.
"Каков народ - такие и бояре" (с) С. Трофимов Другими словами, проблемы стандартизации, точнее классификации стандартов практически полностью отражают извилистый путь страны. Даже отдельный стандарт нередко гуляет по трем ГОСТ (СССР), ГОСТ Р - национальный, и снова ГОСТ уже межгосударственный. Не исключен и обратный ход в ГОСТ Р. А есть еще гармонизированные категории ГОСТ ИСО/МЭК и ГОСТ Р ИСО/МЭК.
Но и это не все. Формально межгосударственный стандарт должен прекратить действие национального. Ну и наоборот, наверное. На практике же вполне может случиться, что один и тот же номер стандарта действует одновременно и в ГОСТ, и ГОСТ Р. И что приоритетнее, непонятно - мнение британских ученых расходятся :)) Тут бы с существующим хаосом разобраться...
И самое главное - обновление стандарта вещь очень инерционная, примерно как внедрение новых лекарств. Изобрести можно за пару недель, а потом лет 10 клинических испытаний.
Поэтому, если кто-то и готовит ИИ-революцию в стандартизации, результат мы увидим ой как нескоро.
Так. Тут мы малость в оффтопик уходим, но ниче, ниче...
Начнем с того, что статья в принципе не для инженеров по стандартизации, а для пользователей системы стандартизации. Это раз. По идее, планируемый итог статьи - кликабельные каталоги ЕСКД, СПДС и ЕСТД, но это уже в канале на Дзене.
Кстати, у врачей действительно есть своя систем стандартизации - это МКБ-10, десятый пересмотр. Сейчас может быть и больше. Так себе системка, несовершенная. Это два.
Сравнивать ИИ и ML не буду, верю вам на слово. Это три. Хотя на мой взгляд эти понятия настолько тесно увязаны, что разделять их можно только в профессиональном приложении, а не в общефилософских рассуждениях.
А вот насчет стандартной структуры и словарей стандартов готов поспорить. На самом деле в статье-то речь идет даже не о структуре самих стандартов, а о их классификационных структурах. Которые должны отражать материальные и нематериальные объекты стандартизации. И таких структур только в пространстве ГОСТ / ГОСТ Р три. А по идее должна быть одна - система стандартов, в которую отлично можно вписать и группы стандартов, и отдельные стандарты. Это четыре.
И пятое. Существующие структуры полны противоречий и двусмысленностей, малую толику которых я вскользь затронул в статье. И вот от этого хотелось бы "очиститься" :))
Не, ну вот первая часть вашей идеи меня искренне восхитила. Зачистка пространства стандартов с помощью ИИ - самое оно. Уверен, что кто-то этим уже занимается. А вторая часть у вас слегка перевернута с ног на голову, ну или на 90 градусов. Входишь да, с человеческим языком, а получаешь - нечеловечески точный. Это достойная цель.
Боюсь, что современный уровень ИИ не позволит. Слишком много двусмысленностей. Хотя конечно, хотелось бы... Это раз. Но не соглашусь на результат - "человеческим языком". Собственно, вся суть стандартизации в том, чтобы превратить неоднозначную человеческую коммуникацию в нечеловечески однообразную.
У Стива Джобса получалось, у Билла Гейтса - нет :))
Разные стили разработки. У вас - БГ :))
Кстати, в вашем развернутом вопросе о компактности содержится и ответ.
Почему json победил... ну не победил конечно, но здорово потеснил xml на большей части поля боя? Не в последнюю очередь потому, что:
значительно компактнее, и более удобочитаемо, чем:
Верно. Она не забыта, и даже deepseek на нее намекал. Но есть нюанс. Как я уже говорил, один из главных приоритетов - компактность, а одно из средств достижения этого приоритета - сокращение области определения. Проще говоря - неопределенные состояния запрещены.
Тем не менее, вам спасибо за комментарий - очевидно, что это ограничение необходимо явно указать в нотации.
И может быть вернуться к этому вопросу в дальнейшем.
И тем не менее. Таков путь.
Компактность для того, чтобы не пришлось скроллить несколько сотен строк.
Признаю ваш аргументы убедительными, что касается и принятия - это вопрос...
Кстати, это и DeepSeek отметил - мол, не все понятно без документации.
Относительно минуса, как NOT. Да, переход от математического контекста к логическому несколько неожидан, особенно если игреки не числа, а строки, к примеру. Но это сделано в угоду компактности, и, полагаю, этот скилл быстро усвоится.
Что касается остального... Намекаете на то, что нет приведения к единой ДНФ, КНФ? Думаю над этим.
Все верно, но... это только первая итерация. В сущности - это тот же json, но безусловно элегантнее.
Смотрите. В действительности задачи данного проекта состоят в следующем:
Сократить формат условных выражений SQL-подобного синтаксиса. Проще говоря, любого, или почти любого выражения WHERE.
Очевидное, но не единственное, решение - конвертация из существующих объектных форматов или форматов передачи данных - json, xml, xsd, yml и т.д. и т.п.
Альтернатива - собственный формат, что и реализовано в предложенном вами решении. Я же остановился на json.
Сократить выбранный объектный формат до минимального за счет сокращения области определения. В данном случае формат json - он же вообще для всего. Предложенный вами формат sql.tree - это конкретная json-подобная реализация полного sql-запроса. Что, в сущности, и является тем самым сокращением области определения. Но... недостаточным.
Потому что здесь речь идет о выражениях WHERE, как о самых проблемных в смысле компактности. А в вашем решении (как и в json) проблема компактности остается, просто из горизонтали переходит в вертикаль, транспонируется.
В любом случае, все это очень любопытно, позже я посмотрю повнимательнее.
Спасибо.
Да, для меня было немного удивительным, что нет простого решения этой проблемы
Спасибо огромное за ваш комментарий, считаю, что с его появлением статья уже свою роль сыграла.
Действительно, с функциями MIN и MAX мой промах. В свое оправдание замечу, что настрой был и остается опираться на чистый SQL: OR, AND, NOT, =, >, <. Потому что применение нотации может оказаться неожиданным, в т.ч и в области, где операторы <= не определены. Этим и объясняется отсутствие IN, а также некоторое дублирование синтаксиса. А наличие-таки BETWEEN, MAX и MIN - это дань лени и спешке.
Что особенно любопытно, хотя и не неожиданно - DeepSeek ошибки с MAX пропустил.
Работать со временем... откровенно говоря, я об этом не думал, но подумаю обязательно.
В общем, спасибо вам еще раз.
Спасибо :))
Это немного не так работает. Автор ГОСТа - это почти всегда лидер рынка, и стандартом он как бы фиксирует свою позицию. Поэтому если ГОСТ меняется, тут два варианта - или лидер пытается укрепить свою позицию, с учетом новых реалий в технологиях, либо другой пытается перенять лидерство, или, по крайней мере, встать рядом.
А получает автор роялти или нет - я не знаю. Но даже если и так, не думаю, что это основной источник финансирования разработчиков. Основной источник - бюджет лидера отрасли.
А речь именно об оформлении. В противном случае, смешивать ЕСКД и СПДС было бы неразумно. А насчет нормоконтроля... Вы не напрасно слово употребили слово "поможет" в кавычках. Тут как повезет.
Ну и насчет фетиша :)) Тут Вы правы, и именно поэтому в обзоре этого нет.
Ну и да... разве не бывает КД, где основная надпись заполнена исключительно одной фамилией, от первой до последней графы, включая "Утв." и "Н.контр." :)) Бывает :))
Дополню ответ. Знаете сколько стандартов числит Росстандарт в СПДС? Предположу, что нет. А я вам скажу - 112. А сколько действующих? 52, вполовину меньше.
Более того, некоторые включены по 3-4 раза, например первый и главный - "Общие положения":
ГОСТ 21.001-93 (СССР, заменен)
ГОСТ Р 21.1001-2009 (РФ, отменен), обозначен с нарушением формата - 1001
ГОСТ 21.001-2013 (СНГ, утратил силу в РФ)
ГОСТ Р 21.001 (РФ, действует)
И так далее. В ЕСКД примерно такая же ситуация. Но это еще ничего, отменены, заменены, утратили силу. Есть же стандарты парные - национальный и межгосударственный, действуют оба, хотя тоже пару тройку раз перевернулись.
Вот для этого и обзор. Для понимания.
Я уже отвечал на похожий вопрос. Это не статья, а обзор, это раз. Второе - обзор рассчитан не на инженеров по стандартизации, и не на нормоконтролеров, а на проектировщиков, преимущественно на начинающих. Третье - обзор предваряет каталоги ЕСКД, СПДС и ЕСТД, которые есть в расширенной статье на канале (указан в конце обзора).
И четвертое - не так уж и просто ищется, повторю - официальные стандарты платные. Неофициальные зачастую тоже платные.
И конечно у профи есть все на жестком диске, ну так они этот обзор и читать не станут. разве что из любопытства.
Ну и вообще... о чем - все написано в самом обзоре, зачем - я пояснил.
верно
так и я из них, только это было оооочень давно :))
Да, по второй части что-то в этом роде. А вот с первой сложнее.
"Каков народ - такие и бояре" (с) С. Трофимов
Другими словами, проблемы стандартизации, точнее классификации стандартов практически полностью отражают извилистый путь страны.
Даже отдельный стандарт нередко гуляет по трем ГОСТ (СССР), ГОСТ Р - национальный, и снова ГОСТ уже межгосударственный. Не исключен и обратный ход в ГОСТ Р. А есть еще гармонизированные категории ГОСТ ИСО/МЭК и ГОСТ Р ИСО/МЭК.
Но и это не все. Формально межгосударственный стандарт должен прекратить действие национального. Ну и наоборот, наверное. На практике же вполне может случиться, что один и тот же номер стандарта действует одновременно и в ГОСТ, и ГОСТ Р. И что приоритетнее, непонятно - мнение британских ученых расходятся :))
Тут бы с существующим хаосом разобраться...
И самое главное - обновление стандарта вещь очень инерционная, примерно как внедрение новых лекарств. Изобрести можно за пару недель, а потом лет 10 клинических испытаний.
Поэтому, если кто-то и готовит ИИ-революцию в стандартизации, результат мы увидим ой как нескоро.
Но хотелось бы, таки, увидеть :)))
:))
Так. Тут мы малость в оффтопик уходим, но ниче, ниче...
Начнем с того, что статья в принципе не для инженеров по стандартизации, а для пользователей системы стандартизации. Это раз. По идее, планируемый итог статьи - кликабельные каталоги ЕСКД, СПДС и ЕСТД, но это уже в канале на Дзене.
Кстати, у врачей действительно есть своя систем стандартизации - это МКБ-10, десятый пересмотр. Сейчас может быть и больше. Так себе системка, несовершенная. Это два.
Сравнивать ИИ и ML не буду, верю вам на слово. Это три. Хотя на мой взгляд эти понятия настолько тесно увязаны, что разделять их можно только в профессиональном приложении, а не в общефилософских рассуждениях.
А вот насчет стандартной структуры и словарей стандартов готов поспорить. На самом деле в статье-то речь идет даже не о структуре самих стандартов, а о их классификационных структурах. Которые должны отражать материальные и нематериальные объекты стандартизации. И таких структур только в пространстве ГОСТ / ГОСТ Р три. А по идее должна быть одна - система стандартов, в которую отлично можно вписать и группы стандартов, и отдельные стандарты. Это четыре.
И пятое. Существующие структуры полны противоречий и двусмысленностей, малую толику которых я вскользь затронул в статье. И вот от этого хотелось бы "очиститься" :))
Не, ну вот первая часть вашей идеи меня искренне восхитила. Зачистка пространства стандартов с помощью ИИ - самое оно. Уверен, что кто-то этим уже занимается.
А вторая часть у вас слегка перевернута с ног на голову, ну или на 90 градусов. Входишь да, с человеческим языком, а получаешь - нечеловечески точный. Это достойная цель.
Боюсь, что современный уровень ИИ не позволит. Слишком много двусмысленностей. Хотя конечно, хотелось бы... Это раз.
Но не соглашусь на результат - "человеческим языком". Собственно, вся суть стандартизации в том, чтобы превратить неоднозначную человеческую коммуникацию в нечеловечески однообразную.