Без заголовка

С пайплайном очень трудно: мы ведь бьем как раз в точку, которая задает пайплайн там, где его до этого не было (у нас ведь описывается жизненный цикл!). В принципе, это разные PLM-системы, но такие системы весьма вендор-специфичны. ISO 15926 дает возможность немного отойти от этой вендор-специфичности и больше думать о задаче, а не о средствах ее решения. Проблема еще и в том, что все PLM настроены на описание workflow, а не жизненных циклов и их практик, как целимся мы. Нынешние PLM сидят все на крошечных участках общего ЖЦ, примеры более обширной интеграции очень редки. Мы движемся от обратного: хотим сделать "описание жизненного цикла для менеджеров и новых сотрудников", а потом его детализировать до уровня, когда возможно непосредственное исполнение в софте его частей. У нас есть примеры успешных таких разработок перед глазами (например, ОргМастер). Так что в данном случае у нас ближе к случаю 3 из вашего коммента. Мы, например, обсуждали вариант взять Simantics и сделать вьюху прямо к нему (он сам сидит над Eclipse, но у него онтологический движок и к нему все необходимые заморочки -- разве что онтология нестандартная, не ISO 15926). У меня понимание того, что я хотел бы иметь в реализации: -- интерфейс, больше похожий на САПР или любой дизайнерский софт, а не "традиционную IDE", абсолютно динамическое редактирование. Вы абсолютно верно указали это в вашем постинге. -- возможность добавлять языки (собственно, это и есть language workbench) -- при добавлении языков сразу указывать на связь с данными из других представлений, и иметь возможность экспортировать результаты (тут важно ISO 15926). В принципе, все современные САПР устроены таким образом (с точностью до различающихся онтологий, но структура этих онтологий близка к ISO 15926, а не к типам языков программирования или схемам баз данных -- она в терминах описания реальности, а не в терминах языков программирования). -- первым "языком=вокабуляром" должен быть ISO 24744 (потому что из него сразу видны выходы во все другие языки: описания продуктов, жизненных циклов, инструментов и т.д.). Увы, все рассматриваемые варианты реализации предполагают либо получение неподъемной громоздкой системы с кучей всего ненужного (типа того же Eclipse) на борту, и отсутствием нужных свойств, либо присутствие нужных свойств и заранее непонятное время программирования с невозможностью даже его оценить. Я думал, что интересное решение можно получить, например развивая Mapper и попутно интегрируясь в IDE Python. Но точно так же сейчас можно вздохнуть, и пересадить алгоритмы Mapper на MPS -- и дальше, сжав зубы, писать на Java. Тут есть еще существенный момент: людям очень не нравится думать о том, что системой типов языка является ISO 15926. Всем хочется писать в "традиционной системе типов языка", а затем мэппиться только в тот момент, когда нужно что-то куда-то передать или что-то откуда-то запросить. Типа как "сила предлагаемого решения в свободе рук программиста, а ISO 15926 -- это как английский, только для межнационального общения". Моя же мысль: а давайте попробуем писать сразу по-английски, какие это может решить наши проблемы? Разница в подходах: английский будут учить либо потом (после начала программирования), либо сначала (до начала программирования). А у меня гипотеза, что пишушие по-английски будут иметь вообще другой стиль программирования -- ибо у них сразу будет другая картина мира (ведь наш метафорический "английский" -- это онтология!). Много, много споров и развилок...