Здравствуйте, vsb, Вы писали:
>>>А на то, что я потратил N человеко-месяцев, у JSON-а нормальных инструментов в принципе нет. Поэтому если они не нужны — разницы между XML и JSON нет почти никакой, оба варианта просты и интуитивно понятны.
I>>Интуитивно-понятно это мягко говоря преувеличение. JSON понятен любому, кто хотя бы кое что пробовал на JS, а это студенты начиная с колледжей.
vsb>Ваши студенты знают JS, но не видели HTML?
Студенты учат или джаву, или С++ и такой синтаксис поняет. JS заходит сам собой. А вот HTML или не видели, или он дает превратное представление об XML.
I>>XML по факту приходится учить в явной форме I>>1 синтаксис — что бы не путали слеши, правильно ставили угловые скобки и тд и тд.
vsb>И сколько этому надо "учить"?
Долго, пока не перестанут тривиальные ошибки делать
I>>2 схемы всякие I>>3 инструментам I>>4 АПИ
vsb>А этого у JSON нет, поэтому и учить нечего.
Схемы, инструменты, апи использовались раньше для тех вещей, которые сейчас делаются совсем иначе.
Раньше было модно использовать XSLT преобразование и подобные чудеса. Сейчас такая хрень никому не нужна. Вместо этого ты отдаёшь данные в чистом виде и дальше клиент, как правило веб, сам всё сделает.
I>>Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом. vsb>В JSON тип вообще никак не определяется, нет стандартных инструментов, есть разного рода попытки.
Здравствуйте, Cyberax, Вы писали:
vsb>>Какие пару часов? Синтаксис XML очевиден за пару минут C>Да? Включая entities, namespace'ы, схемы, кодировки и т.д.?
entities это просто escape-ing. Не сложнее "\uabcd". Вроде есть какая-то муть с DTD, но оно никому не надо. Что там с кодировками, я не знаю, UTF-8 и всё. Остального в JSON нет и к синтаксису это не относится, поэтому из сравнения вычёркиваем, сравниваем сравнимое. Аналог JSON это конструкция вида
<?xml version="1.0"encoding="UTF-8"> <!-- это магическая строчка -->
<tag> <!-- это тег -->
<another-tag> <!-- это вложенный тег -->
<foo bar="qwerty"> <!-- это атрибут -->
<foobar/> <!-- это самозакрывающийся тег -->
</foo> <!-- это закрывающий тег -->
</another-tag>
</tag>
Всё. Этого хватает, чтобы работать с XML на уровне JSON. Всё остальное это уже надстройки, и если мы сравниваем их, то надо включать аналогичные стандарты для JSON (которых нет).
Здравствуйте, Ikemefula, Вы писали:
vsb>>А этого у JSON нет, поэтому и учить нечего.
I>Схемы, инструменты, апи использовались раньше для тех вещей, которые сейчас делаются совсем иначе. I>Раньше было модно использовать XSLT преобразование и подобные чудеса. Сейчас такая хрень никому не нужна. Вместо этого ты отдаёшь данные в чистом виде и дальше клиент, как правило веб, сам всё сделает.
XSLT и подобные чудеса никуда не девались. В JSON их не завезли, да, это печаль. Поэтому видимо и не нужна Что предлагает JSON для конвертации из одного формата в другой? Про "отдаёшь данные в чистом виде" не надо, в реальном мире потребность в конвертации возникает на каждом шагу. Всё, что может предложить JSON это писать логику на ЯП общего назначения, которая будет заведомо проигрывать специализированному языку вроде XSLT или CDuce. И хорошо, если этот ЯП общего назначения достаточно мощный. А чаще всего пишут на убогом JS рассыпную лапшу из десятков if-ов.
I>>>Вот-вот. В XML тип определяется схемой. В JSON — синтаксисом. vsb>>В JSON тип вообще никак не определяется, нет стандартных инструментов, есть разного рода попытки. I>Покажи, для чего тебе нужны инструменты
Для чего нужна XML Schema? Во-первых для документирования формата. Причём это документирование может использоваться умными редакторами для очень удобного редактирования XML, если вдруг это нужно. Во-вторых для первичной валидации данных на соответствие формату. В-третьих для автоматической генерации кода сериализатора, который будет преобразовывать данные из XML в объекты целевого ЯП. Есть ещё много интересных применений, например WSDL, позволяющий в два клика связывать программы на совершенно разных языках, платформах и тд, без каких-либо затрат на разработку парсера, сериализатора, валидатора и других скучных, далёких от бизнес-логики вещей.
Здравствуйте, vsb, Вы писали:
vsb>>>Какие пару часов? Синтаксис XML очевиден за пару минут C>>Да? Включая entities, namespace'ы, схемы, кодировки и т.д.? vsb>entities это просто escape-ing. Не сложнее "\uabcd". Вроде есть какая-то муть с DTD, но оно никому не надо.
Авотщаз. Можно определять custom entities, которые будут содержать куски XML:
<?xml version="1.0"?>
<!DOCTYPE some [<!ENTITY test "This is a test<script>Mwhaha</script>">]>
<some>
&test;
&test;
</some>
Здравствуйте, vsb, Вы писали:
vsb> Всё, что может предложить JSON это писать логику на ЯП общего назначения, которая будет заведомо проигрывать специализированному языку вроде XSLT или CDuce. И хорошо, если этот ЯП общего назначения достаточно мощный. А чаще всего пишут на убогом JS рассыпную лапшу из десятков if-ов.
Можно вопрос? А вы сами писали сколь-либо сложные шаблоны на XSL?
Попробуйте. Если применять XSL не для замены одного тэга на другой, то что-либо внятное на нём превращается в жутикового тормозного монстра. После которого обычный ЯП будет казаться манной небесной, даже с учётом XML DOM API, спроектированного полными дебилами.
Ну и таки аналоги XSL для JSON есть, причём более мощные: http://jsoniq.org/ Просто они нужны далеко не всем, вот и непопулярны.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vsb, Вы писали:
vsb>>>>Какие пару часов? Синтаксис XML очевиден за пару минут C>>>Да? Включая entities, namespace'ы, схемы, кодировки и т.д.? vsb>>entities это просто escape-ing. Не сложнее "\uabcd". Вроде есть какая-то муть с DTD, но оно никому не надо. C>Авотщаз. Можно определять custom entities, которые будут содержать куски XML:
Можно, но, как я и писал, никому оно не надо. DTD почти нигде не используется (т.к. Schema это более удобная и мощная альтернатива) и в парсерах зачастую вообще отключается. Опять же рассматриваются возможности, аналогов которым у JSON нет.
Здравствуйте, Cyberax, Вы писали:
vsb>> Всё, что может предложить JSON это писать логику на ЯП общего назначения, которая будет заведомо проигрывать специализированному языку вроде XSLT или CDuce. И хорошо, если этот ЯП общего назначения достаточно мощный. А чаще всего пишут на убогом JS рассыпную лапшу из десятков if-ов. C>Можно вопрос? А вы сами писали сколь-либо сложные шаблоны на XSL?
Относительно сложные писал и поддерживал, в пару сотен строк (несколько десятков строк логики).
C>Попробуйте. Если применять XSL не для замены одного тэга на другой, то что-либо внятное на нём превращается в жутикового тормозного монстра. После которого обычный ЯП будет казаться манной небесной, даже с учётом XML DOM API, спроектированного полными дебилами.
"Что-нибудь внятное" на SQL тоже превращается в жуткого тормозного монстра и зачастую приходится этого монстра переписывать на традиционном ЯП, разбивая на несколько простых запросов. Это же не повод отказываться от SQL. Так и тут. Есть определённые границы применимости и в их рамках XSLT очень удобен.
Здравствуйте, Cyberax, Вы писали:
C>Можно вопрос? А вы сами писали сколь-либо сложные шаблоны на XSL?
Я писал.
C>Попробуйте. Если применять XSL не для замены одного тэга на другой, то что-либо внятное на нём превращается в жутикового тормозного монстра.
Не превращается.
C> После которого обычный ЯП будет казаться манной небесной
На этих задачах — точно не будет.
C>Ну и таки аналоги XSL для JSON есть, причём более мощные: http://jsoniq.org/
Здравствуйте, vsb, Вы писали:
C>>Авотщаз. Можно определять custom entities, которые будут содержать куски XML: vsb>Можно, но, как я и писал, никому оно не надо. DTD почти нигде не используется (т.к. Schema это более удобная и мощная альтернатива) и в парсерах зачастую вообще отключается.
Речь шла о том, что "да весь XML за 10 минут можно изучить!". Нет, нельзя. И про такие особенности надо знать, иначе можно получить уязвимость в своём приложении.
vsb>Опять же рассматриваются возможности, аналогов которым у JSON нет.
Схемы для JSON тоже есть.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>http://jsoniq.org/docs/JSONiq-usecases/html/ch01.html#json2json НС>XQuery тоже такое умеет. Однако популярности, в отличие от XSLT, так и не получил.
XSLT её тоже не особо получил. Просто долгое время он был единственным "официальным" способом делать преобразования XML. XSLT появился в 97-м году, а XQuery — в 2007-м, когда на XML уже начали забивать.
Здравствуйте, Cyberax, Вы писали:
НС>>XQuery тоже такое умеет. Однако популярности, в отличие от XSLT, так и не получил. C>XSLT её тоже не особо получил.
А это откровенная неправда.
C> Просто долгое время он был единственным "официальным" способом делать преобразования XML.
Преобразовывать любым понравившимся языком программирования его никто не запрещал.
C> XSLT появился в 97-м году, а XQuery — в 2007-м, когда на XML уже начали забивать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>XQuery тоже такое умеет. Однако популярности, в отличие от XSLT, так и не получил. C>>XSLT её тоже не особо получил. НС>А это откровенная неправда.
Так не получил. Где вот он сейчас используется?
C>> Просто долгое время он был единственным "официальным" способом делать преобразования XML. НС>Преобразовывать любым понравившимся языком программирования его никто не запрещал.
Долгое время официальным способом сохранить XML было использовать идентичное преобразование. XSL форсировался везде, куда только можно. XSL-FO все помнят, например?
C>> XSLT появился в 97-м году, а XQuery — в 2007-м, когда на XML уже начали забивать. НС>Оно и видно как все на XML забили.
Ну кто-то продолжает кушать кактус, понимаю.
Здравствуйте, Cyberax, Вы писали:
C>>>XSLT её тоже не особо получил. НС>>А это откровенная неправда. C>Так не получил. Где вот он сейчас используется?
В миллионе сайтов и корморативных систем.
C>>> Просто долгое время он был единственным "официальным" способом делать преобразования XML. НС>>Преобразовывать любым понравившимся языком программирования его никто не запрещал. C>Долгое время официальным способом сохранить XML было использовать идентичное преобразование.
Чего?
C> XSL форсировался везде, куда только можно. XSL-FO все помнят, например?
НУ так вот XSL-FO, не смотря на формирование, так популярности и не получил. А вот XSLT — получил.
НС>>Оно и видно как все на XML забили. C>Ну кто-то продолжает кушать кактус, понимаю.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А это откровенная неправда. C>>Так не получил. Где вот он сейчас используется? НС>В миллионе сайтов и корморативных систем.
Что-то я сомневаюсь в миллионах. В моём локальном корпоративчике, например, я не встречал XSL. Хотя у нас есть экзотика типа Rust и Scala. Так что какой-либо существенной роли XSL не играет.
Можно посмотреть на SO: http://stackoverflow.com/search?q=XSL — всего 38 тысяч вопросов.
C>>Долгое время официальным способом сохранить XML было использовать идентичное преобразование. НС>Чего?
Того. В DOM API от W3C не определено как сохранять документы. Поэтому для той же Java долгое время официальный способ выглядел так:
Transformer transformer = TransformerFactory.newInstance().newTransformer();
Result output = new StreamResult(new File("output.xml"));
Source input = new DOMSource(myDocument);
transformer.transform(input, output);
Не, потом это всё поправили, когда XML стал на практике нужен. В .NET сразу сделали правильно, например.
НС>>>Оно и видно как все на XML забили. C>>Ну кто-то продолжает кушать кактус, понимаю. НС>Отличный аргумент.
Ну таки ведь да.
Здравствуйте, Cyberax, Вы писали:
C> В моём локальном корпоративчике, например, я не встречал XSL.
Да ты много чего не встречал. И регулярно делаешь одну и ту же ошибку — считаешь что твои локальные задачи это все. что в природе существует. Я еще помню твои давние разглагольствования про задачу составления расписания, и глобальные выводы об ORM и РСУБД, которые ты на ее основании делал.
C> Хотя у нас есть экзотика типа Rust и Scala.
Зная тебя уверен — подтасовку ты сделал намеренно. http://stackoverflow.com/search?q=XSLT
C>>>Долгое время официальным способом сохранить XML было использовать идентичное преобразование. НС>>Чего? C>Того. В DOM API от W3C не определено как сохранять документы. Поэтому для той же Java
Это личные проблемы джавы.
C>Не, потом это всё поправили, когда XML стал на практике нужен. В .NET сразу сделали правильно, например.
И не только в .NET.
НС>>Отличный аргумент. C>Ну таки ведь да.
.NET Core will be expanding its API support to include the Mono API surface area, to support Unity / UWP apps
.NET Core will be back in web browser (for some reason) again once WebAssembly finishes
Mscorlib may, or may not be coming back. Or maybe we’ll be using NuGet. #YOLO
AppDomains and other excluded features may be coming back, but different
HgLab: Mercurial Server and Repository Management for Windows
