Универсальный текстовый формат

Б-гоугодный православный XML, вестимо. Ничего лучше просвещённое человечество пока не придумало.

Кстати, мысль, да, спасибо. Я уж было поотвык от него в пользу json, т.к. XML многословен. Но в данном случае вполне себе норм.

А из XML можно в PDF через XSL-FO рендерить. Может и в эксель можно, не интересовался.

csv

зачем тебе текстовый если человек читать не будет? пиши в protobuf

Cvs, json, yaml.

XML'я боишься?

Зайдя в тему, сразу увидел первый комментарий.

Аналогично. И я его совет к выбору XML поддерживаю.

А почему текстовый, если это промежуточный формат для съедения машиной, а не человеком?

читаемый человеком формат
XML

кхм.

Читаю XML вслух. Дорого.

Cvs

Надо разметку: «новая страница», «закрасить это сереньким» и т.д. :). Не понимаю как с этим может Cvs справится.

json

Вот фактически и выбираю между ним и XML, но сейчас склоняюсь к XML.

yaml.

Не использовал почти, кроме pipelines. Формат чистый, да, но отступы немного смущают.

А почему текстовый, если это промежуточный формат для съедения машиной, а не человеком?

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

xlsx это и есть зазипованый xml

А из XML можно в PDF через XSL-FO рендерить. Может и в эксель можно, не интересовался.

Спасибо за наводку. Надо поизучать, возможно, это как раз то, что нужно.

xlsx это и есть зазипованый xml

Ну руками его едва ли кто-то будет писать (есть, например, тот же Apache POI). Тем более, потом лезть туда с диффом.

Excel … XLSX…

XLSX - архив множества XML. Если уж ты считаешь это читаемым, то Excel может и просто одним XML сохранить (и такие даже циркулируют в принудительном документообороте). Libreoffice умеет Flat XML ODF. Это лучше ложится на системы контроля версий, чем бинарники, но не так хорошо, как исходники.

и ожидаемого XLSX

Внезапно эксель открывает специально подготовленный xml, html ну и csv на которые можно писать тесты. XLSX это если нужны хитрые формулы, графики и т.п. безобразие, а для банальных таблиц есть ИМНО более кошерные форматы для экселя.

Освой R.

CSV? Формата проще для табличных данных просто не придумаешь

Если уж ты считаешь это читаемым, то Excel может и просто одним XML сохранить (и такие даже циркулируют в принудительном документообороте). Libreoffice умеет Flat XML ODF.

Я пользователям не объясню, почему в их версии офиса фокумент не открывается или открывается не так. А сейчас формат корректно открывается более-менее всеми современными версиями разных реализаций табличного офиса в разных ОС.

Внезапно эксель открывает специально подготовленный xml, html ну и csv на которые можно писать тесты.

Всякий ли эксель? Из под macOS тоже корретно откроет? И потом, это не решает вопрос с PDF.

Освой R.

Его реально из под JVM поднять? Он умеет стили в результирующих документах?

CSV? Формата проще для табличных данных просто не придумаешь

Я не спорю, но стили тоже имеют значение. Как же их в CSV писать?

XLSX и есть XML.

XLSX - это ZIP из XML-ов. Но в любом случае, читать и писать его руками, наверное, не самая распространенная практика. Для этого есть готовые библиотеки.

У латеха сомнительная человекочитаемость. А любое представление таблиц помимо конечного читаемым не будет как ни крути.

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

Вообще, в моём понимании, в случае с таблицами данные как раз таки не важны, не смысла их как-то описывать, а вот шаблон таблицы очень даже важен. И ещё, как уже предлагали выше — YML, я лет 8 назад научил сотрудников небольшого офиса писать в нём отчётики (на основе готовых шаблонов и плагина для саблайма), получилось удобно.

Например https://www.renjin.org/

R умеет всё

Б-гоугодный православный XML, вестимо. Ничего лучше просвещённое человечество пока не придумало

Ты пробовал читать XML и тебе показалось, что это удобно? Точно? Как по мне, так этот каргокультный формат не подходит ни для чего, кроме своей основной функции — редкие ссылки, картинки, и переносы строк в сплошном тексте. Человеку его читать сложно без помощника поиска соотносящихся тэгов, машине его парсить тоже тяжело, как ни странно. Я не считаю JSON каким-то идеальным решением, но он на голову выше XML, и именно поэтому является основным форматом для REST-мусора, хотя JS и питон могут парсить как XML, так и JSON.

Ты пробовал читать XML и тебе показалось, что это удобно?

Последние 15 лет пользуюсь XML и мне удобно.

Как по мне, так этот каргокультный формат не подходит ни для чего, кроме своей основной функции — редкие ссылки, картинки, и переносы строк в сплошном тексте.

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

Человеку его читать сложно без помощника поиска соотносящихся тэгов

Соотносящиеся теги в общем-то абсолютно очевидны, т.к. закрывающие повторяют открывающие теги. В отличие от json, в котором }}}}} заставляет буквально на пальцах отсчитывать, какая скобка чего закрывает.

машине его парсить тоже тяжело, как ни странно

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

Я не считаю JSON каким-то идеальным решением, но он на голову выше XML, и именно поэтому является основным форматом для REST-мусора, хотя JS и питон могут парсить как XML, так и JSON.

Сколько работаю, никогда не видел, чтобы кто-то по своей воле использовал REST. Всегда генерируют WSDL и использовать Web Services.

Я до сих пор не видел аналога SoapUI для REST.

В конторе, где я проработал шесть лет, REST-идеология и JSON-форматы были на каждом шагу. И хорошо, что были. Собственно, и сейчас есть (только меня там нет), вот, например, пост: https://gizmodo.com/fantasy-football-league-total-loser-sentenced-to-24-hou-1... — а вот он же но для любых целей кроме показа конечному пользователю: https://gizmodo.com/api/core/post/1847133017

Ты пробовал читать XML и тебе показалось, что это удобно?

Последние 15 лет пользуюсь XML и мне удобно

Хм-м-м, дай угадаю... удобно так же, как удобно писать на Java? То есть, при помощи инструмента, который позволяет этот язык полуавтоматически обрабатывать.

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

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

Соотносящиеся теги в общем-то абсолютно очевидны, т.к. закрывающие повторяют открывающие теги. В отличие от json, в котором }}}}} заставляет буквально на пальцах отсчитывать, какая скобка чего закрывает

Да, и поэтому во многих форматах разметки и конфигов закрывающие символы просто отсутствуют. Но по крайней мере в JSON они меньше отсвечивают.

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

Не в том смысле, что это грузит процессор, а в том смысле, что программисту непросто сформировать-интерпретировать содержимое XML:

http://nothing-more.blogspot.com/2004/10/where-xml-goes-astray.html

Я уже не помню, сколько раз я обсирался с пробелами в XML. Да, здесь нужен дополнительный уровень трансляции. Вторая упомянутая в статье проблема — это атрибуты. Которые подразумевали только латиницу и цифры. По итогу в форматах данных атрибуты по возможности избегают, и получается

<obj>
  <zero></zero>
  <first>one</first>
  <second>two</second>
</obj>

которое неудобно парсить руками, потому что нельзя просто сделать obj['first'] — а вдруг узлов first несколько? Опять-таки, мы приходим к необходимости дополнительного слоя трансляции. То есть, мы снова и снова приходим к одной и той же проблеме — XML сам по себе не предназначен для отображения данных, в нем нет простых и ассоциативных массивов, в нем есть мешающиеся под ногами пробелы (например, первым дочерним узлом в <obj> является текст с переводом строки и пробелами, а не <zero>).

Сколько работаю, никогда не видел, чтобы кто-то по своей воле использовал REST. Всегда генерируют WSDL и использовать Web Services

Да, вроде этой прокладки. Потому что парсить сам XML тяжело. Что и требовалось доказать.

Я до сих пор не видел аналога SoapUI для REST

JMeter?

Так смотря какие данные, может и ini-файл норм будет

Хм-м-м, дай угадаю… удобно так же, как удобно писать на Java? То есть, при помощи инструмента, который позволяет этот язык полуавтоматически обрабатывать.

Наличие инструментов это только плюс. И без хороших редакторов XML гораздо проще читается/пишется в обычном блокноте, нежели JSON.

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

Я не только задумывался, но и честно про это написал. Без XML Schema с массивами неудобно, а значит лучше JSON. С XML Schema проблемы массивов исправляются.

Да, и поэтому во многих форматах разметки и конфигов закрывающие символы просто отсутствуют. Но по крайней мере в JSON они меньше отсвечивают.

Так это плохо, а не хорошо. "foo":{"bar":....}}}}},"baz": к чему относится baz, к тому же уровню, то foo, bar или как? Непонятно, надо считать скобки. В XML сразу будет видно что-то вроде </bar><baz> и вопросов просто не возникает.

Я уже не помню, сколько раз я обсирался с пробелами в XML. Да, здесь нужен дополнительный уровень трансляции. Вторая упомянутая в статье проблема — это атрибуты. Которые подразумевали только латиницу и цифры. По итогу в форматах данных атрибуты по возможности избегают, и получается

С пробелами не сталкивался, но с атрибутами точно нет никаких проблем, не нужно там только латиницу и цифры, что хочешь, то пиши.

JMeter?

Это сарказм был. Невозможно создать такой инструмент для REST. Он по определению не интроспектируем. Пока документацию не прочитаешь от корки до корки, не поймёшь, что туда слать надо. А SoapUI проглатывает WSDL и сразу тебе генерирует пример запроса, в которые достаточно подставить нужные данные и можно прямо к себе в программу копипастить.

Хм-м-м, дай угадаю… удобно так же, как удобно писать на Java?

Мир Java давно уже выкидывает XML на помойку в пользу JSON, YAML и лапши из аннотаций. Например, тот же Spring. Ну и в пользу наколенных DSL’ов, вроде Groovy-script, Kotlin-script и прочего новомодного из популярного Gradle на замену полумёртвому Maven’у с XML’ом.

Так это плохо, а не хорошо. «foo»:{«bar»:….}}}}},«baz»: к чему относится baz, к тому же уровню, то foo, bar или как? Непонятно, надо считать скобки. В XML сразу будет видно что-то вроде и вопросов просто не возникает.

Если это будет читать человек, то нужны отступы. И будет вполне красиво.

https://json.org/example.html

С отступами что угодно будет красиво. Только не всегда они есть.

Вот когда выкинут, тогда и приходите. А пока что последний Spring прекрасно работает с XML, и слава богу.

Всякий ли эксель?

Он один msExcel

Из под macOS тоже корретно откроет?

А куда ему деваться? Микрософтовский стандарт один для всех с небольшими вариациями по версиям.

И потом, это не решает вопрос с PDF.

С PDF проблем нет и никогда не было - генеришь свои типовые pdf под свои шаблоны и бинарно сравниваешь, главное метадату времени выставлять одну и ту же.

Если отступов нет, то это не для человека. Поэтому функции json_encode() в РНР можно отдать дополнительный параметр флагом JSON_PRETTY_PRINT, который будет генерировать жсон с отступами, разрывами строк.

html

А из XML можно …

В 100% правда, в XML все можно. И в 99% случаев нету никакой необходимости.

csv, json, yaml

xml - ублюдок, медленный, многословный, неоднозначный, нетипизированный, не маппящийся в базовые контейнеры ЯП, не читаемый ни человеком ни машиной. Для тестов и диффа точно непригодный.

fods (libreoffice)

Суть не в том, что можно, а в том, что уже написано, причём лет 15 назад, то бишь все баги давно пофикшены и остаётся только сконфигурировать.

Все уже раз и навсегда придумано

https://github.com/commonmark/commonmark-java

https://mvnrepository.com/artifact/com.atlassian.commonmark/commonmark

Скорее всего будет не так, будет помирающая в ASF Java библиотека с последним релизом в 2013ом году где уже раз и навсегда пофикшены все баги и они умеет генерировать вырвиглаз

Интерсная штука, спасибо, но, как я понял у него вывод только в HTML.

Посмотрите в сторону

https://github.com/vsch/flexmark-java

Мне самому интересно попробовать - есть некоторые задачи, по формированию doc и pdf.