XSLT 2 и 3 - почему их поддержку не добавляют в браузеры?

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

XML, как и иные языки разметки имеют лишь некоторую нишу задач, для которых использование их приемлемо.

Пост не об том, что xml якобы плох.

«Пост не об том, что xml якобы плох.»

Ну так почему поддержку XSLT 3 не добавляют в Firefox тогда?

А в чём должна выражаться эта поддержка? Какие задачи должна решать?
Зачем нужно выпиливать?

Добавить можно что угодно, но время и ресурсы у разрабов не бесконечные. Лучше спросите об этом в их багтрекере/фичтрекере и скиньте ссылку сюда, будем отслеживать. Чем на воде гадать.

Ну так почему поддержку XSLT 3 не добавляют в Firefox тогда?

Не знаю.

С использованием XSLT (к примеру) не сложно реализовать отчетник, который
весьма упростит формирование большой ниши отчетов.

Проблема в том, что лишь «некой ниши отчетов», но не отчетника типа Fastreport.

Или, если он такой ненужный, то почему не выпиливают поддержку 1.0 ?

Потому что это может поломать некоторые сайты. Да и выпиливание чего-то - тоже работа.

чтобы разработчики в корпоративных мясорубках догнивали до понимания его преимуществ

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

В современном браузере не должно быть никаких проблем реализовать нужный функционал на JS или Wasm. Если оно, конечно, вообще кому-то надо. Нет никакой особой нужды сувать реализацию прям в браузер.

технология уже утратила актуальность

Вот я и хочу понять, почему утратила, не на пустом же месте технология возникла. Что теперь эту технологию заменяет. Не понимаю.

не должно быть никаких проблем реализовать нужный функционал на JS

И как этот JS использовать? вместо одного .xslt-файла должны идти два: .js-файл + .html файл?

А в чём должна выражаться эта поддержка?

Ну очевидно в том, чтобы xslt применялся к xml. Примерно как css применяется к html.

Какие задачи должна решать?

Работа с документами в браузере без всяких js.

почему утратила

Ну это же xml. Даже в свои золотые годы оно не особо доминировало.

Что теперь эту технологию заменяет. Не понимаю.

React, Angular, Vue. Ну, не напрямую. Вместо xslt+xml теперь вот фронтэндные фреймворки+json.

мне непонятно, как описывают метаданные к json. в XML-то там данные от метаданных отделены угловыми скобками. а в json метаданных просто нет. Значит они должны быть в отдельном файле. Что почитать?

Значит они должны быть в отдельном файле.

Ну или вообще не быть.

Что почитать?

Как хранить метаданные в джейсон? Да как угодно)

https://json-schema.org/draft/2020-12/json-schema-core.html

Это штука для проверки корректности json, соответствует ли json документ некой структуре. Типа аналог XML Schema. Это не про то, что в xml в угловых скобках.

Но это как бы не что-то обязательное, без чего веб не обходится)

Xml уже не модно.

Почему? Выше написали, что у XML есть уникальная фича, которой нет в JSON, это элементы и атрибуты.

Мода не поддается логике

Вот я и хочу понять, почему утратила, не на пустом же месте технология возникла. Что теперь эту технологию заменяет. Не понимаю.

Как минимум утратила потому, что формат XML утратил актуальность. Ну и практика показала, что вместо написания этих XSLT проще просто взять и написать нормальный код, хоть на том же JS.

И как этот JS использовать? вместо одного .xslt-файла должны идти два: .js-файл + .html файл?

Как напишешь так и будешь использовать. Например - вместо XSLT-файла будет идти HTML-файл, в нём JS, который будет выкачивать XSLT и XML откуда надо, применять его и отображать в каком надо виде.

Например - вместо XSLT-файла будет идти HTML-файл, в нём JS, который будет выкачивать XSLT и XML откуда надо, применять его и отображать в каком надо виде.

Это я уже проходил.

То, что ты называешь метаданными, в JSON это просто строки.

К примеру XML вида

<person name="Ivan">
 <children>
  <person name="Petr">
 </children>
</person>

может быть показан в виде JSON

{
 "person": {
  "name": "Ivan",
  "children": [{
   "person": { "name": "Petr" }
  }]
 }
}

если тебе так уж важно сохранять эту строку «person» по какой-то причине.

В чём тогда вопрос?

Проблема в том, что мне XML нравится больше чем JSON. А другие люди говорят что это ненормально и у меня проблемы с головой, лень, и нежелание изучать JSON.

нежелание изучать JSON

Не болей, и, главное, не перенапрягайся, изучая САМ json)))

А другие люди говорят что это ненормально и у меня проблемы с головой, лень, и нежелание изучать JSON.

Их просто нервирует, что ты ворошишь древние артефакты типа xslt или xml schema, аналоги которых хоть и есть в джейсон, но о них мало кто знает, потому что они не нужны (вот кто знает, что для жейсона есть еще аналог xpath?). Тут целая церемония парсинга, sax или dom, в то время как юзеры джейсона даже не знают, как их парсер называется. Зачем нужно читать древние талмуды, наверняка ты замышляешь что-то нехорошее, ведь по джейсон вообще ничего не надо читать.

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

Нравиться должны девушки, а к технологиям нужно подходить прагматично. В истории было много хороших технологий, канувших в лету. Нет смысла за них цепляться. Тот же XML это лишь бледный отблеск SGML, но кого это волнует. Ты вряд ли будешь писать свою XSLT-реализацию. Если тебя не устраивает та, что в браузере, и те, что доступны в публичных библиотеках, ну - таков мир, нет - значит нет.

Если взять твой пример по той ссылке, всё, что тебе надо, это заменить new XSLTProcessor() на new XSLT3Processor(), реализацию которого ты должен написать сам или найти в интернете, вдруг кто-то уже написал. Требовать от браузера что-либо кроме поддержки JavaScript тут некорректно. Браузер может поддерживать либо то, к чему у JS принципиально нет доступа (новые API), либо то, что на JS будет тормозить, при этом это используется очень многими (к примеру новые видеокодеки). XSLT ни к тому, ни к другому не относится.

Ну а то, что он таки поддерживает какую-то старую версию XSLT, можно считать лишь тяжёлым историческим наследием. Разговоры о том, чтобы эту поддержку выкинуть находятся ещё в 2013 году. Цена этой поддержки в целом вполне осязаемая - полмегабайта у каждого пользователя хрома на планете ради 0.003% страниц.

XSLT это client-side рендеринг.

Во-первых, мой недавний «опрос» показал, что его противников больше трети.

Во-вторых, XLST – это крайне многословный и громоздкий рендеринг. Писать на таком, прости господи, «языке» – всё проклянёшь.

В-третьих, он вообще не нужен, т.к. в 99.99% случаев весь рендеринг сводится к подстановке блоков на страницу, и XSLT тут – из пушки по воробьям.

И в-четвёртых он тоже вообще не нужен, т.к. чтобы его заюзать, надо на сервере сериализовать данные в XML, отдать клиенту, клиент запросит XSLT и преобразует XML в HTML. А не проще ли на сервере сразу сериализовывать данные в HTML, раз их один хрен приходится сериализовывать?

Как-то так.

их приходится сериализовывать

А хранить перед сериализацией как, если не в XML, чего эти ваши freeorion и open office document хранят в XML, а не в JSON?

А хранить перед сериализацией в базе.

P.S. https://rsdn.org/forum/humour/7310395

JSON выполняет требование «хранить в текстовом формате», он не хуже XML. Хранить в базе - это страшный бинарный формат, он не соответствует требованию.

Вот прикольный пример, где он уместен, имхо.

https://feeds.bbci.co.uk/news/rss.xml

Если у тебя на входе УЖЕ xml, и это не твой выбор, т.е. никуда от него не деться, то возможно. И то не факт. RSS-простыня плоская, с простой структурой, такое на севрере тупо SAX-ом (streaming со входа на выход, без загрузки всей простыни в память) распарсить и просто, и поэффективнивнее будет раз эдак в несколько. А XSLT работает с DOM.

В принципе я набрёл на реализацию XSLT3 на JS. Наслаждайся. https://www.saxonica.com/saxon-js/index.xml

Суть в том, что у тебя эндпоинт RSS должен выдавать XML. Но кто-то может захотеть открыть его в браузере. Если ничего не делать, получится стрёмная фигня. А они добавили стиль и получилось читаемо.

Можно, конечно, по Accept определять браузер и отдавать конкретно ему HTML, но это кажется не слишком хорошей идеей.

В целом согласен. По данному конкретному юз-кейсу.

Анализировать Accept и отдавать HTML – на самом деле очень хорошая идея. Концептуально. Ибо это REST в полный рост. Но практически, с точки зрения лени – XSLT проще. Но это единичный случай, о чём выше неоднократно уже говорилось (про то что XML скорее мёртв чем жив), и пляшут тут не от удобства юзеров, а от технологии и удобства программистов.

«SaxonJS is free of charge but not open source.»

(я не очень понимаю, как это возможно в случае JavaScript)

Binary form: In this license, «binary form» means the form in which the Software is issued (this is technically a set of obfuscated JavaScript files).

Нуу, ясно.

Потому что есть json - для веба нативный формат данных встроенный в js, мейнстримный клиентский яп. Ты просто берешь json eval-ишь его и получаешь js-объект и дальше делаешь с ним всё что угодно причем на императивном, понятном большинству языке и всё это в рамках стандартного веб2.0 стека html + js + css. Для большинства применений в вебе этого достаточно. Если тащить в проект еще и xml+xslt, то получается, что нужно в стек включать еще один довольно плохо читабельный и не очень распространенный среди кодеров язык(xslt, xml можно не считать, он близок с современным html до смешения), а собственно ради чего?

Не знаю как сейчас, но ещё пару лет назад банально не было нормальных открытых средств для разработки. Имеется в виду с нормальным дебаггером, калькулятором XPath и валидатором схем.

Для XSLT 2 лучшее из того, что было, это Exchanger, в статусе abandonware, без исходников, собранный с древней версией saxon. Для XSLT 3 не было вообще ничего, только проприетарь за конский прайс.

XSLT 2.0 утверждён, на секунду, в 2007 году.

https://github.com/search?q=XSLT

Полно разработанных библиотек.
Проблема в чем-то другом.

К примеру для 1С понадобилось мне API совместимое с MSXML3.
Взял TinyXML2 v3.0 и добавил в него недостающие классы и методы (за две недели).

class XMLDocument;
class XMLElement;
class XMLAttribute;
class XMLComment;
class XMLNode;
class XMLDOMNodeList;
class XMLDOMSelection;
class XMLText;
class XMLDeclaration;
class XMLUnknown;
class XMLPrinter;

XSLT 2 и 3 - почему их поддержку не добавляют в браузеры?

Я вижу 3 причины:

1. Не всегда нужен рендеринг на стороне клиента. Проще и быстрее сделать на стороне браузера. А на сервере свой шаблонизатор используется.

2. Очень многословный xslt. Есть менее многословные шаблонизаторы.

3. Увеличивается время рендеринга в браузере: надо сначала загрузить xml, потом загрузить xslt, потом css и js. Быстрее сразу загружать html, который подмножество xml

В этом ИТТ треде обсуждалось использование в масс-сегменте, в web-разработке.

Вести разработку в блокноте на функциональном ЯП - занятие не для каждого, продукт-менеджеру такую идею не продашь. Библиотек в гитхабе не многим больше, чем на SAS - тоже узко специализированном языке, бесполезном за пределами своей экосистемы, для которого нет и не будет сторонних IDE.

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

Сразу вспомнился

https://github.com/EvilBeaver/OneScript  Кросс-платформенная реализацией виртуальной машины, исполняющей
скрипты на языке 1С:Предприятие

https://github.com/oscript-library  Пакеты для 1Script

1С-сникам это не сильно нужно.
Тогда вопрос - «Для кого?».

Тогда вопрос - «Для кого?».

А как Вы вообще себе видите будущее - русские вымрут? И станут англоговорящими, или будут писать иероглифами? Это потому что русские какие-то недоделанные по-вашему? Если «доделанные» и нормальные (кстати, русские - самый многочисленный народ европы), то почему нельзя делать языки программирования на родном алфавите? Потому что с Вами что-то не так?

Любопытное обвинение.
Годами на этом форуме защищал Россию от нападок, ...

И в мыслях не было хулить проекты, использующие Русский язык.

Вош вопрос «для кого» как бы подразумевает, что не нужно создавать кириллические языки программирования. Этим вы демотивируете русских разработчиков от разработки такого типа программного обеспечения, снижаете количество опыта по созданию компиляторов и таким образом способствуете будущему стратегическому отставанию России. Единственное, чем Вы сможете искупить свою вину перед народом и страной - воспитать троих патриотов.

Вош вопрос «для кого» как бы подразумевает, что не нужно создавать кириллические языки программирования.

Речь шла о нише пользователей конкретного проекта (а не всех Российских проектов и.т.д., и.т.п.).

Вот если для OneScript разработают поддержку хотя бы нескольких объектов 1С, то
пожалуй для меня этот проект станет интересен.

Единственное, чем Вы сможете искупить свою вину перед народом и страной - воспитать троих патриотов.

Вот где вы раньше были?
Лишь двоих воспитал.
Сын в Питере живет, дочь в Ростове-на-Дону.

Вот где вы раньше были?

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

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

Троллинг - «не мое».