Сообщение Re[10]: Microsoft: Всеобщая json'ификация? от 13.05.2016 13:42
Изменено 13.05.2016 13:43 Sinix
Здравствуйте, 0BD11A0D, Вы писали:
S>>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
BDA>Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Ну и ок. Раз заказчик формат — так и выгружаем. Другой заказчик попросит смесь из атрибутов/контента, третий ещё что-то придумает, в любом из вариантов у нас будет валидный xml. С json всё печальней, там даже схем толком нет.
BDA>Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
Ну давай от темы не уклоняться, м? Проблема у вас по факту была не в "нужны только атрибуты / контент", а в том, что вы пытались обмениваться xml без схемы. В общем, вы узнали, зачем нужны xsd сложным способом.
BDA>1. Зато такой XML, в свою очередь, плохо ложится на SQL;
Все нормальные базы наотлично умеют в xml. В том числе и разбирать xml на отдельные записи.
BDA>2. Зато правильно писать такой XML труднее;
Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
BDA>3. Зато (были?) проблемы с парсингом.
Ну как бы обсуждали уже. Проблема оказалась не с парсингом. Проблема в том, что вы выдавали xml, не подходящий под формат заказчика. Снова нутыпонял
BDA>Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру.
А, ну тогда мы об одном и том же говорим. И я не сказал бы, что это что-то новое (перевод). Смотрим на дату поста
BDA>А будущее, все-таки, за Node.JS и json.
Воот очень с большим скепсисом. Не, в первые два-три раза можно повестись. А вот когда подобных "наше всё" перевидал с десяток и все как одна в итоге сдулись в свою родную нишу, на очередные решения-для-всего всерьёз смотреть не получается.
S>>Ну блин, снова вы на следствия смотрите, а не на первопричины.
BDA>Евангелизм меня мало интересует и их самопиар тоже.
Чой то вас снова занесло. Вам расписывают как оно на самом деле обстоит, а вы про евангелизм начинаете. Фу-фу-фу так делать.
S>>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
BDA>Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Ну и ок. Раз заказчик формат — так и выгружаем. Другой заказчик попросит смесь из атрибутов/контента, третий ещё что-то придумает, в любом из вариантов у нас будет валидный xml. С json всё печальней, там даже схем толком нет.
BDA>Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
Ну давай от темы не уклоняться, м? Проблема у вас по факту была не в "нужны только атрибуты / контент", а в том, что вы пытались обмениваться xml без схемы. В общем, вы узнали, зачем нужны xsd сложным способом.
BDA>1. Зато такой XML, в свою очередь, плохо ложится на SQL;
Все нормальные базы наотлично умеют в xml. В том числе и разбирать xml на отдельные записи.
BDA>2. Зато правильно писать такой XML труднее;
Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
BDA>3. Зато (были?) проблемы с парсингом.
Ну как бы обсуждали уже. Проблема оказалась не с парсингом. Проблема в том, что вы выдавали xml, не подходящий под формат заказчика. Снова нутыпонял
BDA>Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру.
А, ну тогда мы об одном и том же говорим. И я не сказал бы, что это что-то новое (перевод). Смотрим на дату поста
BDA>А будущее, все-таки, за Node.JS и json.
Воот очень с большим скепсисом. Не, в первые два-три раза можно повестись. А вот когда подобных "наше всё" перевидал с десяток и все как одна в итоге сдулись в свою родную нишу, на очередные решения-для-всего всерьёз смотреть не получается.
S>>Ну блин, снова вы на следствия смотрите, а не на первопричины.
BDA>Евангелизм меня мало интересует и их самопиар тоже.
Чой то вас снова занесло. Вам расписывают как оно на самом деле обстоит, а вы про евангелизм начинаете. Фу-фу-фу так делать.
Re[10]: Microsoft: Всеобщая json'ификация?
Здравствуйте, 0BD11A0D, Вы писали:
S>>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
BDA>Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Ну и ок. Раз заказчик формат выбрал — так и выгружаем. Другой заказчик попросит смесь из атрибутов/контента, третий ещё что-то придумает, в любом из вариантов у нас будет валидный xml. С json всё печальней, там даже схем толком нет.
BDA>Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
Ну давай от темы не уклоняться, м? Проблема у вас по факту была не в "нужны только атрибуты / контент", а в том, что вы пытались обмениваться xml без схемы. В общем, вы узнали, зачем нужны xsd сложным способом.
BDA>1. Зато такой XML, в свою очередь, плохо ложится на SQL;
Все нормальные базы наотлично умеют в xml. В том числе и разбирать xml на отдельные записи.
BDA>2. Зато правильно писать такой XML труднее;
Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
BDA>3. Зато (были?) проблемы с парсингом.
Ну как бы обсуждали уже. Проблема оказалась не с парсингом. Проблема в том, что вы выдавали xml, не подходящий под формат заказчика. Снова нутыпонял
BDA>Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру.
А, ну тогда мы об одном и том же говорим. И я не сказал бы, что это что-то новое (перевод). Смотрим на дату поста
BDA>А будущее, все-таки, за Node.JS и json.
Воот очень с большим скепсисом. Не, в первые два-три раза можно повестись. А вот когда подобных "наше всё" перевидал с десяток и все как одна в итоге сдулись в свою родную нишу, на очередные решения-для-всего всерьёз смотреть не получается.
S>>Ну блин, снова вы на следствия смотрите, а не на первопричины.
BDA>Евангелизм меня мало интересует и их самопиар тоже.
Чой то вас снова занесло. Вам расписывают как оно на самом деле обстоит, а вы про евангелизм начинаете. Фу-фу-фу так делать.
S>>Ну по-хорошему да. В смысле, не пользователя менять, а подход. Или просить заказчика предоставить xsd-схему (это заодно решает 1000 других вопросов), или не притворяться, что у вас валидный xml.
BDA>Ну, дадут схему, а там одни аттрибуты. Или все в ноды свалено. И что? Если техническая проблема имеет место, схема ее не закроет.
Ну и ок. Раз заказчик формат выбрал — так и выгружаем. Другой заказчик попросит смесь из атрибутов/контента, третий ещё что-то придумает, в любом из вариантов у нас будет валидный xml. С json всё печальней, там даже схем толком нет.
BDA>Просить заказчика об xsd-схеме, когда он сам в ней не заинтересован, это, зачастую, итальянская забастовка. На свободном рынке обструкционизм несовместим с заработками. Может, еще функциональную спецификацию просить?
Ну давай от темы не уклоняться, м? Проблема у вас по факту была не в "нужны только атрибуты / контент", а в том, что вы пытались обмениваться xml без схемы. В общем, вы узнали, зачем нужны xsd сложным способом.
BDA>1. Зато такой XML, в свою очередь, плохо ложится на SQL;
Все нормальные базы наотлично умеют в xml. В том числе и разбирать xml на отдельные записи.
BDA>2. Зато правильно писать такой XML труднее;
Все нормальные редакторы умеют проверку xml-я на базе xsd-шек. Снова "просто используй нормальные инструменты".
BDA>3. Зато (были?) проблемы с парсингом.
Ну как бы обсуждали уже. Проблема оказалась не с парсингом. Проблема в том, что вы выдавали xml, не подходящий под формат заказчика. Снова нутыпонял
BDA>Любая метафора имеет свои ограничения. Для меня важно, что Майкрософт в погоне за новыми рынками забивает на текущую клиентуру.
А, ну тогда мы об одном и том же говорим. И я не сказал бы, что это что-то новое (перевод). Смотрим на дату поста
BDA>А будущее, все-таки, за Node.JS и json.
Воот очень с большим скепсисом. Не, в первые два-три раза можно повестись. А вот когда подобных "наше всё" перевидал с десяток и все как одна в итоге сдулись в свою родную нишу, на очередные решения-для-всего всерьёз смотреть не получается.
S>>Ну блин, снова вы на следствия смотрите, а не на первопричины.
BDA>Евангелизм меня мало интересует и их самопиар тоже.
Чой то вас снова занесло. Вам расписывают как оно на самом деле обстоит, а вы про евангелизм начинаете. Фу-фу-фу так делать.