xml - не так и страшен :)

← →
12 © (2010-03-29 14:27) [0]

думал все выходные, как бы половчее написать обменник с филиалами

ADODataSet1.SaveToFile("wewewe.xml", pfXML);
ADODataSet2.LoadFromFile("wewewe.xml");

все :)
i love delphi!!

← →
Sergey13 © (2010-03-29 14:42) [1]

А в чем тут ловкость то? ИМХО самое сложное при репликации определить ЧТО отправлять и КАК интерпретировать присланное.
А формат - хоть голубиной почтой.

← →
12 © (2010-03-29 15:04) [2]

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

← →
test © (2010-03-29 15:12) [3]

12 © (29.03.10 15:04) [2]
Ты просто пока с ошибками не столкнулся.

← →
sniknik © (2010-03-29 15:58) [4]

проблемы не тогда когда пишешь/читаешь одним методом в любом формате (лучше использовать "родной", чтобы не преобразовывать), а тогда когда тебе в этом "универсальном" будет кто то другой данные предоставлять. тогда то то вся "универсальность" и "накроется".

а тут..., например замени pfXML на pfADTG и посмотри изменилась "ловчесть" обменника? а ведь уже не xml... + будет еще размер меньше.

а с другой стороны выгрузи также в xml из клиентского рекордсета, а загрузить попробуй в ado-шный... вот тебе и первая проблема, хотя xml, а толи еще будет когда пойдет обмен между разными участниками...
как говорится "плавали, знаем"...
и все бы ничего, все решается, но только для многих (особенно менеджеров) xml это как панацея, ибо "универсальный!"(произносится с придыханием, а после через паузу "а у вас, что не понимает?"), и хрен объяснишь, что структуру нужно обговаривать в любом случае, что сделанное самопальными парсерами мало кто поймет, что если в заголовке стоит win-1251 а внутри все в неизвестной науке кодировке то это проблема, что размер важен!, что может быть нестандартный указанием в заголовке интерфейса каким его требуется разбирать (тогда необходим еще и сом обьект от него) и т.д. все объяснения разбиваются об "он же универсальный" (универсальность понимают не в том, что на нем многое возможно, а в том что раз на нем значит все могут использовать...)

← →
Медвежонок Пятачок © (2010-03-29 16:05) [5]

что сделанное самопальными парсерами мало кто поймет

яя натурлих.
именно поэтому и XML

← →
Медвежонок Пятачок © (2010-03-29 16:08) [6]

И все таки он универсальный.
потому что:
1. на клиенте (винде) его разобрать можно всегда, ибо парсер есть в голой ОС
2. на SQL сервере его разобрать можно всегда (если в нем есть поддержка типа xml) (настоящие сервера ее имеют)
3. можно создавать herfvb как plain text и читать тоже.

4. куча еще причин по которым он универсальный.

← →
Palladin © (2010-03-29 16:11) [7]

а я вообще за json

← →
Медвежонок Пятачок © (2010-03-29 16:12) [8]

а могу я в оракле иметь таблицу с полем типа json?

фик. не могу. а надо.

← →
Медвежонок Пятачок © (2010-03-29 16:14) [9]

а могу я в голой vs2008 сделать linq запрос к документу json?
нет?
а пачиму?

← →
Медвежонок Пятачок © (2010-03-29 16:16) [10]

а могу я в голом браузере без плугинов открыть файл json в красивой древовидной форме?
нет?
а пачиму?

← →
Медвежонок Пятачок © (2010-03-29 16:18) [11]

а могу я сделать трансформ джейсон документу и получить на выходе rtf,html,txt или другой джейсон?

← →
sniknik © (2010-03-29 16:20) [12]

> яя натурлих.
> именно поэтому и XML
ответственность, и договоренность придерживаться одного формата/использовать только стандартный парсер совершенно не относятся к свойствам формата.

> а пачиму?
мелкософт не его "продвигает"

> а я вообще за json
а я за "родной" формат, т.е. обмен стараться делать на тех данных в которых работаешь, или с минимальными преобразованиями.

← →
sniknik © (2010-03-29 16:22) [13]

> а могу я сделать трансформ джейсон документу и получить на выходе rtf,html,txt или другой джейсон?
ну а кто ж знает твои способности? вообще парсеры/конвертеры подобные есть (для html использовал).

← →
Palladin © (2010-03-29 16:27) [14]

> а могу я в голом браузере без плугинов открыть файл json
> в красивой древовидной форме?

нет, но ты можешь сделать var o = eval(jsonString) и получить готовый объект js

> а могу я в голой vs2008 сделать linq запрос к документу
> json?нет?а пачиму?

если мс это не поддерживает, то нет, а зачем?

> а могу я в оракле иметь таблицу с полем типа json?

а зачем? строки чем не угодили?

> а могу я сделать трансформ джейсон документу и получить
> на выходе rtf,html,txt или другой джейсон?

можешь, но надо написать утилиту

НО, я абсолютно согласен с sniknik"ом, по поводу передачи толп данных в каком либо из описательных форматов, они, описательные форматы, не для того создавались, НО я за использования оных для: хранения опций, обменом небольших пакетов данных, запросов-ответов

просто json мне более симпатичен, приятен для глаза (а для чего еще были созданы описательные форматы как не для глаза)...

← →
Медвежонок Пятачок © (2010-03-29 16:37) [15]

а зачем? строки чем не угодили?

ну вот надо мне.
приходят данные из внешнего мира в виде xml.
я их складирую в поле типа xml.
на худой конец я их помещаю аз из в варчар.

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

← →
Медвежонок Пятачок © (2010-03-29 16:39) [16]

можешь, но надо написать утилиту

а для xml этого не требуется.
или почти не требуется.
точнее не требуется в том объеме в каком это потребуется для json.

в голой ос только что после установки это уже досупно.

зачем мне это надо?

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

и все это с минимальнейшими затратами времени.

← →
Медвежонок Пятачок © (2010-03-29 16:46) [17]

просто json мне более симпатичен, приятен для глаза

Это вообще не аргумент.
Поясняю почему.

Представьте программиста прошлого века (тетеньку например предпенсионного возраста). Она всю жизнь имела дело с дибейсом, а о клиент-серверной технологии не слышала даже.

Тут к ней приходите вы и говорите, что намного круче юзать оракл/мсскл/fb/etc

Она вам говорит: а нука дайте глянуть внутрь ораклового формата. и нажимает ф3 в нортон командере на файле данных оракла.

Ее последующая реакция - это почти дословно ваш аргумент о более симпатичном джейсоне.

Но правда жизни-то в том, что те, кто понимает, тот не жмет ф3 на файле данных оракла.

← →
Palladin © (2010-03-29 17:28) [18]

> Но правда жизни-то в том

вот меня еще жизни неучили, иди поразбирай тонны логов запросов-ответов, да бы найти тот который процессинг отшил.... попросматривай трассировку ajax запросов-ответов веб-приложения... бабка и ф3 тут вообще ни причем...

← →
Palladin © (2010-03-29 17:34) [19]

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

← →
Медвежонок Пятачок © (2010-03-29 17:42) [20]

Еще раз для тех кто жмет ф3.

Мне вообще по барабану как там внутри хмл представлены данные.
И по барабану текстовые они или бинарные.

По барабану, понимаешь?
Точно так же мне по барабану как устроен физически файл данных оракла.

У меня есть адекватные инструменты для работы с xml и я с ними работаю и инструментов этих - тысячи.

иди поразбирай тонны логов запросов-ответов

И в чем проблема?
Я лет десять как программирую в основном неинтеракитвное ПО, которое генерит логов не меньше чем у тебя.
И проблем не испытывал не разу.

← →
Медвежонок Пятачок © (2010-03-29 17:46) [21]

почему бы не использовать бинарный формат ИД-значение?

странный вопрос.

а почему например утф-8 не сделать бы бинарным?
не круто же.

← →
Медвежонок Пятачок © (2010-03-29 17:56) [22]

> а пачиму?
мелкософт не его "продвигает"

мелкософт не продвигает. замечательно.

А что насчет иных?

Могу я в других браузерах увидеть иерархию джейсона?
Могу я в других скл серверах оперировать типом данных джейсон?

Не могу. Точнее конечно могу, если нагенерю для этого тонны кастомного кода.

Вот и все. Больше ничего и не требуется доказывать.

← →
sniknik © (2010-03-29 18:09) [23]

> Я лет десять как программирую в основном неинтеракитвное ПО, которое генерит логов не меньше чем у тебя.
> И проблем не испытывал не разу.
сколько клиентов тебе присылает данные? не ты, записал/прочитал, а вот по твоему описанию "как надо", тебе присылают в "как хотим".

или мало, или очень везет. формат вообще тут дело десятое... проблемы вызывает не он, а миф о нем. что стоит только перевести на xml и все тебя станут понимать...

ну вот пойми к примеру, почитай "в удобном" виде, и скажи что мно отсюдя в базу сохранять? (я знаю, но ты тоже должен слету прочитать "универсальный", т.к. говориш проблем с ним не имеешь)
<?xml version="1.0" encoding="WINDOWS-1251"?><userinfo><extid>115543709</extid><fio>РљРѕС‰Р°РєРѕРІР° РќР°С‚Р°Р»СЊСЏ РќРёРєРѕР»Р°РµРІРЅР°</fio><doc>78 08662584</doc><phone>9201165114</phone><encdate>hQIOA39DGzuBhmYHEAf/SGoNabl4E0c1ZTyscGE0MrD0WaXWvr1a4+0yhTqqKaxjN2+VgRmim/L/aUesESu1sat3Cn4sl9ih6c8vN27LAhBEPI/O5TvoWKZbTAiYgqSddy4JgGKE1IJ0YBlJexhONiAPU+lj+OeiGN+DG6b77LiQv5CJmptXiuWdotaDHoUzX6gteNuNpTGKIKh3MNzHE1N8CxccBQVy9+yqJ1skpdfL850vYXODw+yRSQLG07fTD3zqR1O2+rjwbQ9Vjn5eSjPphBxGOrpFeRQc5rDspaVUiUV3LN5JO6IKg/5BT9SYHGbBIxoHBD/5tJHYBxaPRRqel7DgVZdKzvXP6EpmKggAgqyAt6mgNVURA1QWBOAKLlbOG7IDv91WPXQR54pleFOhqt8 zsn6C9NBTz+7r6seH8Y2GlRCEApN6kIxiEvuM1Eo6WgrMHt642Yg1ZuTEmAjXipZpMEaNjnXDEM6Vs7Ou59aSlTYPJ5 wj2Ak+G7u+9jutxGRzYokYGUoK0kfYVrOGuQ8qAZWBDztao1xpaQZmOClgmZtOwmCCrYc/PHSjmZgBsQzzL1TOAgSyQ5jSvkLPf0noxfdhAlGDFmjIVCBhCMa6IR5E7LpdYgea2NVZflmAGdBAGhA/CCzLmjioj4CiL7/xeUHR4fgM07VpfYN6wr6Mq2t7Mdqzk2Z7NSFVAqQ2VKeG0gFv/6rdeCdwCzRMLlzM4QsvCw84bbI88Turxg3x7hoh875BYFZLB+0BzMa3jPHboHjC=NJEm</encdate><srvtype>1</srvtype><resp_msg/><reg_dt/><templates><template><templid>mts</templid><paymsum>10000</paymsum><paymsubjtp>115</paymsubjtp><params><param code="307" num="1">9108780689</param></params><status>1</status></template><template><templid>default</templid><paymsum>10000</paymsum><paymsubjtp>111</paymsubjtp><params><param code="150" num="1">9204465164</param></params><status>1</status></template></templates></userinfo>

← →
sniknik © (2010-03-29 18:10) [24]

кстати то что там utf-8 догадаться не так уж и сложно, ты поле encdate расшифруй... что оно значит.

← →
Игорь Шевченко © (2010-03-29 18:15) [25]

sniknik © (29.03.10 18:09) [23]

Мне (точнее, заказчикам) дофига присылают. И что ?

> а миф о нем. что стоит только перевести на xml и все тебя
> станут понимать...

по крайней мере тебя смогут проверить до того, как понять

← →
Медвежонок Пятачок © (2010-03-29 18:21) [26]

<?xml version="1.0" encoding="WINDOWS-1251"?>

1с делает похожие дибейс файлы.
Данные в cp866, а в заголовке написано что анси.
И что дальше?
Скажем фу дибейсу?

← →
Медвежонок Пятачок © (2010-03-29 18:23) [27]

а миф о нем. что стоит только перевести на xml и все тебя станут понимать...

Ну а если все перевести на джейсон, то миф про всеобщее понимание сразу исчезнет? И все всех поймут?

← →
Кщд (2010-03-29 19:35) [28]

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

но XML - это и валидация(XSD) и интуитивно понятная навигация (XPATH) и преобразования (XSL/XSLT) и - черт возьми - запросы(XQuery)
кроме всего, готовые генераторы классов десериализации - надавил кнопочку и получил готовый класс по схеме
т.е. богатый функционал, масса готовых библиотек
XML давно и по праву стандарт обмена - де факто

← →
sniknik © (2010-03-29 19:52) [29]

> Мне (точнее, заказчикам) дофига присылают. И что ?
тогда скажи мне, что в encdate в примере. ты счас в том же положении/знаешь столько же, сколько я когда мне дали этот формат.
могу чуть чуть приоткрыть больше (чтобы вообще на равных)
это замена обмена который был, и очень хорошо себя чувствовал на dbf-е. замена произошла по "веяниям" всеобщей xml-изации, типа "мы должны использовать!".
и кстати если ты скажешь что там внутри старый dbf то будешь не далек от истины, но не все таки не прав. ну так, чем его заменили?

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

> 1с делает похожие дибейс файлы.
1c делает foxpro файлы, и все там у него правильно.

> И что дальше?
> Скажем фу дибейсу?
скажи фу своему проклевывающемуся ламеризму.

> Ну а если все перевести на джейсон, то миф про всеобщее понимание сразу исчезнет? И все всех поймут?
json никогда не рекламировали как универсальный формат для обмена данными, т.что да, миф исчезнет.
ну, а так как в силу той же рекламы менеджеры знают только про xml... то при любом другом формате они прибегут советоваться со специалистами, перестанут делать "умные" решения договариваясь о получении данных из базы вместо в файле бэкапа, в xml-е.

в общем со своей стороны вижу только плюсы если перейти, но только ты меня не слушал, не на json (json мне нравится, и он удобен когда работаешь с аяксом/в html/+(?), а когда у тебя dbf таблицы то почему ми и и не обмениваться?), а на "родной" формат/близкий к тому на чем работают, хотя бы с одной стороны.

← →
sniknik © (2010-03-29 19:57) [30]

> но XML - это и валидация(XSD)
попробуй "состыковаться" с MTC, формат приема платежей/точек. XSD там есть, и даже вполне себе приличные XSD. но думаешь проблем нет? это один из самых отвратительных форматов с каким сталкивался. (кто делал подтвердите/опровергните)

← →
Игорь Шевченко © (2010-03-29 20:03) [31]

sniknik © (29.03.10 19:52) [29]

Не совсем понимаю, почему кривые руки ваших поставщиков данных должны как-то сопоставляться с языком ?

> тогда скажи мне, что в encdate в примере. ты счас в том
> же положении/знаешь столько же, сколько я когда мне дали
> этот формат.

Зачем мне чего-то говорить - посмотри в схему, там все написано

← →
Медвежонок Пятачок © (2010-03-29 20:12) [32]

> 1с делает похожие дибейс файлы.
1c делает foxpro файлы, и все там у него правильно.

> И что дальше?
> Скажем фу дибейсу?
скажи фу своему проклевывающемуся ламеризму.

Экие мы категоричные.
Ну вот есть разработчик. Делфиец.
Договорились обмениваться дибейсом.
Приходит такой вот "правильный" фокспрошный дибейс.
Внутри у него не написано что он фокспрошный.
Бде в нем видит третий дибейс.
А кодировка раком.

← →
sniknik © (2010-03-29 20:18) [33]

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

> Зачем мне чего-то говорить - посмотри в схему, там все написано
схемы нет. по телефону ответ - бинари дата.
дальше?

хотя все одно не догадаешься, скажу так. там данные из того самого dbf, в текстовой табличке, символами псевдографики, и соответственно OEM (dos) кодировке, которая (чтобы не "ломалась", т.к. там символы вида & присутствуют "завернуты" в подобие base64 (а может в неудавшуюся попытку)). на вопрос зачем такие сложности, был ответ, почти по Пятачку - ну удобно же! (они ее "разворачивают", и как есть подсовывают в какой то печатаемый отчет).

← →
Медвежонок Пятачок © (2010-03-29 20:21) [34]

мое удобство реальное.
и оно в том, что обработка может быть как клиентская, так и серверная.
а может вообще никакой обработки не быть а просто сохранение в первозданном виде.
и из этого первозданного вида я могу получить все что хочу (снова как на клиенте так и на сервере)

← →
sniknik © (2010-03-29 20:23) [35]

> что сам по себе xml ничего не значит.
> Договорились обмениваться дибейсом.
а вот договор, и его строгое соблюдение значит.

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

← →
Медвежонок Пятачок © (2010-03-29 20:26) [36]

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

← →
Кщд (2010-03-29 20:28) [37]

> XSD там есть, и даже вполне себе приличные XSD. но думаешь
> проблем нет? это один из самых отвратительных форматов с
> каким сталкивался. (кто делал подтвердите/опровергните)

сопрягались с агрегаторами услуг - никаких проблем
да и XSD - для валидации, к "читабельности" данных отношения не имеет
по поводу encdate: разве json в этой ситуации чем-то лучше?

← →
sniknik © (2010-03-29 20:30) [38]

> и сравним профит.
пример из
sniknik © (29.03.10 15:58) [4]
выгрузи из клиентского, загрузи в адошный.

← →
Кщд (2010-03-29 20:32) [39]

>Кщд (29.03.10 20:28) [37]
>сопрягались с агрегаторами услуг - никаких проблем
поясню: агрегаторы - это те, кто реально проводит платежи из уличных CashIn-аппаратов: МТС, Билайн, НТВ+ и др.

← →
Медвежонок Пятачок © (2010-03-29 20:33) [40]

выгрузи из клиентского, загрузи в адошный.

рисую один xsl и делаю один единственный вызов метода.
на выходе получаю адошный xml.

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

> сопрягались с агрегаторами услуг - никаких проблем
у всех свой протокол, я привел конкретно МТС.

> по поводу encdate: разве json в этой ситуации чем-то лучше?
а кто такое говорил?

но переделали именно из-за xml, чтобы говорить, мы поддерживаем xml! не понятно? было бы такое из-за json-а не любил бы json.

sniknik © (29.03.10 20:18) [33]

> я то их как раз не сопоставляю, почитай тему сначала

Как раз ты и сопоставляешь - если мне прислали плохой XML, то виноват не тот, кто его прислал, а сам XML, потомушта менеджеры и т.д. json rulezz, xml suxx, далее со всеми остановками до станции Можайск Смоленского направления.

> схемы нет.

Что еще раз говорит о кривизне рук

← →
Кщд (2010-03-29 20:41) [43]

>sniknik © (29.03.10 20:30) [38]
а зачем мне грузить в АДО-шный?
если нужен объект, сгенерирую по схеме класс(набор классов).
если нужен dataset - сгенерирую и его по той же схеме(XSD): xsd.exe из поставки студии

универсальный формат - не значит, что ничего не нужно писать
и уж тем более, не означает, что XML - решение проблем со странно-зашифрованными/отформатированными данными
здесь, действительно, надо согласовывать и согласовывать - согласен с Вами полностью и безнадежно
речь о том, что работать с XML крайне удобно, в отличии...

> кто реально проводит платежи из уличных CashIn-аппаратов: МТС, Билайн, НТВ+ и др.
т.е. тебя не "напрягло" то, что при регистрации точки один xml с заголовком, вкладывается в другой тоже с заголовком. и если внешний может быть в любой кодировке (в соответствии с указанным в заголовке) то внутренний обязательно в windows-1251, независимо от заголовка... и в документации этот нюанс не отражен (или не был, может сейчас уже есть).
ну а так как мы делали обмен на php используя utf-8 везде, то... (ошибок не дает, внешний разбирается, и валидацию проходят оба), но данные не записывает... т.к. внутри в базе кто-то там его напрямую как таблицу открывает без учета заголовка.
выясняли долго долго. (дня 2 такую фигню)

← →
Кщд (2010-03-29 20:45) [45]

> sniknik © (29.03.10 20:34) [41]
> у всех свой протокол, я привел конкретно МТС.

в частности, были платежи МТС

> > по поводу encdate: разве json в этой ситуации чем-то лучше?
>
> а кто такое говорил?
>
> но переделали именно из-за xml, чтобы говорить, мы поддерживаем
> xml! не понятно? было бы такое из-за json-а не любил бы
> json.

Вы расставили точки над "i" - помстилось, что обсуждаем XML vs JSON

Игорь Шевченко © (29.03.10 20:38) [42]
ты видишь только то что хочешь, а не то что написано.

> а зачем мне грузить в АДО-шный?
доказать универсальность, зачем же еще. мне. т.к. я в нее не верю.

> что обсуждаем XML vs JSON
Palladin его вообще зря упомянул, отвлекает от смысла темы.

← →
Кщд (2010-03-29 20:53) [48]

>sniknik © (29.03.10 20:44) [44]
про регистрацию точки, честно, не понял
про вложенные также слышу впервые(или просто забыл? - работал над проектов три года назад) - мы работали через cyberplat, у них в документации, насколько помню, было четко указано win-1251

накладок не было - всё согласно доке(это даже докой называть смешно - несколько страниц word), благо, степеней свободы там не много - платеж либо прошел, либо нет
если не прошел, показываем клиенту ошибку от агрегатора

плюс в том, что не нужно было писать свои парсеры/генераторы для этого формата, т.к. это - XML
и сложностей не возникло, когда обработку переносили с PHP на Oracle PL/SQL, т.к. фактически - copy/paste - сплошной XPATH

доказать универсальность, зачем же еще. мне. т.к. я в нее не верю.

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

Итак: есть клиентский пакет и надо получить адошный. Зачем?
Видимо для того, чтобы сделать лоадфромфайл на адодатасете.

Чтобы что потом сделать?
Очевидно что инсерт в бд (чтобы снова не возиться с этим же клиентским пакетом)

так ведь эта задача решается легко и просто и без удаления гланд через анус.

про вложенные также слышу впервые

Есть есть там такое. Причем не только в транспортных данных.

Внутри конфигов например лежат приватные ключи в виде вложенного фрагмента xml

Что верно то верно. - XML сам по себе не гарантирует от перекосов в мозге и карме.

sniknik © (29.03.10 20:47) [46]

Так ты пиши разборчивее :)

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

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

← →
Кщд (2010-03-29 21:01) [52]

>sniknik © (29.03.10 20:47) [46]
>доказать универсальность, зачем же еще. мне. т.к. я в нее не верю.
передача в формате XML не расшифрует элемент <encdate> - факт
универсальность для меня в том, что у меня есть готовые библиотеки для работы конкретно с этим форматом для (практически) любого современного ЯП, что позволяет создавать языко-независимые(простите за косноязычие) программные интерфейсы
сейчас, например, использую т.н. "xml-шлюз", идеология которого - "xml на вход, xml на выход"
клиенты на Oracle PL/SQL, Firebird PSQL(здесь сложнее - без UDF никак...), PHP и - моё любимое - мобильное приложение на compact framework
всё это без написания format specific библиотек на каждой конкретной платформе

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

> Итак: есть клиентский пакет и надо получить адошный. Зачем?
не получить, получить я легко могу, а использовать как есть. ведь универсальность это должна позволять.

> Очевидно что инсерт в бд ...
> так ведь эта задача решается легко и просто и без удаления гланд через анус.
не возражаю, возьми клиентский и открой его сразу в базе (mssql) так как ты рекламировал до этого.
а я поковыряюсь, найду(если найду, давно все таки было) тебе старый пример с персональным парсером... (без регистрации нужной dll не разбирается), попробуешь с ним потом.
что тоже доказывает универсальность (но только ту ли, что понимают?)

а использовать как есть. ведь универсальность это должна позволять.

в смысле использовать?
понятие слишком широкое.

получив однажды пакет - использовать его данные многократно?
так у меня же и клиент-датасет никто не отнимал.
ели его у меня отняли я как уже говорил один раз сочиняю файл xsl трансформации, гружу исходный пакет в один документ, трансформацию в другой, вызываю трансформ - получаю адошный пакет.
итого: всего три метода.

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

и уже из таблицы буду его грузить в адодатасет

← →
Кщд (2010-03-29 21:12) [55]

>sniknik © (29.03.10 21:04) [53]
>но только ту ли, что понимают?
собственно, вокруг этого и вьется дискуссия
ту ли, что понимают "менеджеры" из Ваших постов? - вряд ли

для меня универсальность именно в

без написания format specific библиотек на каждой конкретной платформе

т.е. для сопряжения с моим сервисом я должен предоставить просто хорошо прокомментированную XSD-схему
всё
никаких требований к ЯП и операционной платформе

> но скорее всего я вообще не буду эти заниматься ...
я сразу предлагал "родной" формат, где возможно.

> собственно, вокруг этого и вьется дискуссия
всего 2 варианта

1 можно сделать все что угодно (многое), и тогда сделанное одним не гарантируется к пониманию другим (что и видим).
2 делай где угодно и как угодно, поддерживают, и поймут все, ибо универсально! (с придыханием. см. мой первый пост). это как видят, и как его рекламировали.

Прочитал ветку и понял, что как всегда билагейтса виновата...

> Прочитал ветку и понял, что как всегда билагейтса виновата...

Имхо - разработчики тк [1]...

xml - не так и страшен :) Найти похожие ветки