Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2009.06.14;
Скачать: [xml.tar.bz2];

Вниз

Поддерживает.. Что за глупое выражение   Найти похожие ветки 

 
12   (2009-04-09 17:50) [0]

- У Вас программа XML поддерживает?
всегда хочется сказать
- Нет. У нас XML и без программы может работать..


 
Ega23 ©   (2009-04-09 17:51) [1]

Есть такие, которые не поддерживают.


 
12   (2009-04-09 17:55) [2]

:)
Зачем его поддерживать, он что, калека?


 
Rouse_ ©   (2009-04-09 17:55) [3]

Это не выражение - это вопрос ;)


 
AndreyV ©   (2009-04-09 18:11) [4]

> [0] 12   (09.04.09 17:50)
> - У Вас программа XML поддерживает?
> всегда хочется сказать
> - Нет. У нас XML и без программы может работать..

Ответь: у нашей программы недержание XML, стоит нажать кнопку - всё поописает XML-ем.


 
Kostafey ©   (2009-04-09 18:12) [5]

> - У Вас программа XML поддерживает?
> всегда хочется сказать

А зачем двайверу пылесоса XML?


> - Нет. У нас XML и без программы может работать..

Впрочем, верно и обратное :)


 
@!!ex ©   (2009-04-09 18:26) [6]

> [0] 12   (09.04.09 17:50)

Это нормальный вопрос.
Не развернутый, это да.
Вариации:
Ваша программа поддерживает сохранение данных в XML?
Ваша программа умеет корректно загружаться из XML?
и т.п.


 
Городской Шаман   (2009-04-09 18:37) [7]


>
> 12   (09.04.09 17:50)
>
> - У Вас программа XML поддерживает?


Хороший формат. У нас вместо ini во всём новом коде используется и для передачи данных в сетевых сообщениях. Ничего нового не нужно придумывать чтобы кинуть произвольное сообщение по сети о котором знает только конкретный объект клиента и севера.


 
iZEN   (2009-04-09 19:21) [8]


> Городской Шаман   (09.04.09 18:37) [7]
> Хороший формат. У нас вместо ini во всём новом коде используется
> и для передачи данных в сетевых сообщениях. Ничего нового
> не нужно придумывать чтобы кинуть произвольное сообщение
> по сети о котором знает только конкретный объект клиента
> и севера.

А оно у вас Well-formed и Valid? Чем докажите? Ж))


 
Zeqfreed ©   (2009-04-09 20:28) [9]

> iZEN   (09.04.09 19:21) [8]

А где реклама суперкласса на яве, который генерирует правильные иксемели?


 
oxffff ©   (2009-04-09 20:31) [10]


> А где реклама суперкласса на яве,


+1


 
sniknik ©   (2009-04-09 21:13) [11]

ненавижу xml... куча проблем из-за тупой уверенности менеджеров его универсальности.
получается им и думать не надо, перетерли между собой "у вас поддерживает? у нас да. и у нас да." и типа все работа сделана.  а то что говорят оба про принципиально разные, по сути не стыкующиеся программы, это не важно. потом "это программисты не могут, а xml универсальный" (прибить бы гада который эту "утку" запустил).
а вот как состыковать учет товара, и учет больных например? по какому критерию? и главное ЗАЧЕМ? но нет, обе "поддерживают xml, значит их надо состыковать"...

Городской Шаман   (09.04.09 18:37) [7]
> Хороший формат.
ну, это тебя просто не вынуждали в этом "хорошем" формате что нибудь делать, там где оно совсем не к нужно. вот например поменять обмен данными внутри программы (!!! наружу там ничего не идет. и структура не меняется. давно устоялась) с бинарного на xml.... и только ради того чтобы можно было гордо сказать "мы поддерживаем!". (а за счет этой поддержки обработка данных стала раз в 10 медленней)

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


 
DVM ©   (2009-04-09 21:29) [12]


> вот не было бы ажиотажа с этой мнимой универсальностью

Да она не мнимая, она реальная, но я тоже не понимаю зачем везде стремятся пропихуть XML, несмотря на то, что 9/10, а то и 19/20 содержимого файла или трафика это ненужные теги.


 
Eraser ©   (2009-04-09 21:34) [13]

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


 
DVM ©   (2009-04-09 21:35) [14]


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

+100 Тоже сталкивался с таким неоднократно.


 
Eraser ©   (2009-04-09 21:36) [15]

> получается им и думать не надо, перетерли между собой "у
> вас поддерживает? у нас да. и у нас да."

поддержка поддержке рознь. можно создать один корневой тег и в него сохранить все данные в BASE64 ))


 
iZEN   (2009-04-09 21:44) [16]


> Eraser ©   (09.04.09 21:34) [13]
>
> просто нет приемлемой и понятной конечному пользователю
> кроссплатформенной альтернативы.

Что это.
Есть JSON.


 
Eraser ©   (2009-04-09 22:14) [17]

> [16] iZEN   (09.04.09 21:44)

те же яйца, только в профиль.


 
iZEN   (2009-04-09 22:38) [18]


> Eraser ©   (09.04.09 22:14) [17]
>
> > [16] iZEN   (09.04.09 21:44)
>
> те же яйца, только в профиль.

Отнюдь.
Сам контент в JSON гораздо компактнее и человекочитабельнее.


 
Ping-Pong   (2009-04-09 22:50) [19]

>>iZEN   (09.04.09 22:38) [18] Сам контент в JSON гораздо компактнее и человекочитабельнее.

Ну и нафига эта читабельность? Ты знаешь много программистов или конечных пользователей, которые просматривают файлы данных в блокноте? Понапридумывали всякой фигни аббревиатурной, чтобы долбать людям мозг и загружать процессоры дебильной работой. А толку - ноль целых хрен десятых! В топку!


 
sniknik ©   (2009-04-09 22:58) [20]

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

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


 
Eraser ©   (2009-04-09 23:07) [21]

> [20] sniknik ©   (09.04.09 22:58)

куда сложнее открыть в делфи данные, сериализованные php-шной serialize или в php данные, сериализованные делфевским TStream.WriteComponent.


 
sniknik ©   (2009-04-09 23:15) [22]

+ вдогонку к [20]
вот к примеру тебе прислали xml (на самом деле я его из примеров здесь вытащил)
http://www.filefactory.com/file/agae82d/n/Onix_xml
открой например эксплорером... получилось? а почему? наверное потому что чегото не хватает, да? я вот думаю универсальности (во втором смысле).


 
sniknik ©   (2009-04-09 23:17) [23]

> куда сложнее открыть в делфи данные, сериализованные php-шной serialize или в php данные, сериализованные делфевским TStream.WriteComponent.
но про них никто и не говорит, что они универсальны и обязаны везде открываться.
т.что тут все в порядке.


 
Eraser ©   (2009-04-09 23:24) [24]

> [23] sniknik ©   (09.04.09 23:17)

дык, а почему [22] не открывается то? у меня прекрасно распарсился с пом. TXMLDocument. думаю с джаваскими и phpшными аналогами тоже проблем быть не должно. документ валидный.


 
Zeqfreed ©   (2009-04-09 23:25) [25]

Какой-то бред, по-моему, обсуждается. Кто где говорит, что использование XML для хранения данных разной структуры обеспечивает совместимость ПО, поддерживающих импорт/экспорт данных из/в эти структуры?

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

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


 
sniknik ©   (2009-04-09 23:25) [26]

он валидный, но IE не открывается. (7м во всяком случае)


 
Eraser ©   (2009-04-09 23:30) [27]

> [26] sniknik ©   (09.04.09 23:25)

а зачем с пом. IE открывать xml-документы? разве что strict-html можно, который базируется на xml...


 
Sergey Masloff   (2009-04-09 23:30) [28]

DVM ©   (09.04.09 21:35) [14]

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

>+100 Тоже сталкивался с таким неоднократно.

- 100 тысяч ;-)
 Если не стыкующиеся то никто их стыковать и не будет. И перетирать никто не будет, это вы ребята трындите, 99.9%
 А вот если чем-то стыкуются то XML пусть не революционную но очень хорошую вещь дал.
 1) XSD. Формат описывается и утверждается. И досвидос - а чегой-то вы неправильно читаете мои данные, ах язабыл предупредить у меня сумма теперь не вторая а третья колонка... все идут лесом. Корректность формата проверяется СТАНДАРТНЫМИ средствами на любой из сторон обмена.
 2) Трансформации
 3) XPATH (уже не так важно но...)
И не надо про то что все это реализуется и для самопридуманых форматах. Устанешь договариваться когда сторон обмена > 2

Лично мне массовое применение XML жизнь облегчило просто кардинально


 
Eraser ©   (2009-04-09 23:31) [29]

> разве что strict-html можно, который базируется на xml...

но он должен быть и оформлен соответственно.


 
sniknik ©   (2009-04-09 23:38) [30]

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

> И не надо про то что все это реализуется и для самопридуманых форматах. Устанешь договариваться когда сторон обмена > 2
зачем же на само придуманных? на том что родное для того с чем работаешь... вот мне чаще всего приходится обмениваться базами (mssql) и сколько ни говорю "только нормальный стандартный бэкап!" все одно шлют всякую хрень.

в других областях то же самое. нужно переслать табличку так почему прям втом dbf-е с которым работает прога и не послать? нафига конвертации, если со 100% вероятностью на том коце будет обратное преобразование из xml в dbf


 
sniknik ©   (2009-04-09 23:47) [31]

кстати насчет "Устанешь договариваться", вот сколько мне с техническими специалистами не приходилось договариваться об обмене данными никогда вопроса не было о формате xml/текст/dbf/... да все одно. что хотите/удобнее то и шлите. обсуждалось содержимое - что слать, какие данные в каких полях...
а вот когда присутствовал на встречах менеджеров, так это наиглавнейший вопрос о формате, а вот "что" даже не упоминается. хотя это важнее.

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


 
oxffff ©   (2009-04-09 23:58) [32]


> sniknik ©   (09.04.09 23:47) [31]


А у нас в России знаете ли много что не делается.
Теперь что касаемо XML, я cейчас попью чаю и постараюсь на примерах объяснить Вам зачем нужен XML.


 
DVM ©   (2009-04-10 00:01) [33]


> Sergey Masloff   (09.04.09 23:30) [28]


> - 100 тысяч ;-)
>  Если не стыкующиеся то никто их стыковать и не будет. И
> перетирать никто не будет, это вы ребята трындите, 99.9%

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


 
oxffff ©   (2009-04-10 00:10) [34]

to sniknik.

Давайте вначале рассмотрим любой произвольный формат. Например формат PE файла.
И так он начинается с основного заголовка с префиксом MZ. Далее в одном из одного его полей следуют смещение на дополнительный заголовок с префиком PE. Все бы ничего однако. Однако есть огромная сложность. Как доказать что переданный Вам файл является PE.
Ведь никто не гарантирует, что какой нибудь парень или девушка напишет программу, которая будет формировать файл с началом MZ и областью PE.
А теперь как же доказать что это именно тот файл. А никак (ну конечно же есть частные способы, но нет универсального). Сложность в том, что значения полей подразумеваются быть на данном месте по определенному абсолютному или относительному смещению от начала файла. То есть по факту есть просто файл значений. Но нет соответствия параметр - значение. Далее продолжим.


 
Хитрий Лис   (2009-04-10 00:19) [35]


> sniknik ©   (09.04.09 23:47)

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

Считаю что мифы о плезности XML полезны для обычных программистов/кодеров - однозначно !
Хотя бы потому, что за разработку мнимой и часто никому не нужной поддержки XML те самые заказчики и глупые менеджеры готовы выделять бюджет и кормить нас с вами :)

PS: Как пример - вот представьте что автомеханики кричат - мол не нужно приезжать к нам в сервис менять масло, фильтры и делать баллансировку, ведь машинка и так прекрасно ездит ;)


 
oxffff ©   (2009-04-10 00:24) [36]

to sniknik.

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

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

и т.д.

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

1. определение формата  
2. проверку его валидности (То есть это то что я ожидаю принять от другого узла)

В силу [34] вы понимаете, что для универсальности необходимо хранить не только значение, но и объект присвоения этого значения.
Далее вы понимаете что у каждого формата есть своя формализованная структура. А что если задать метаинформацию об структуре данных в вашем файле.

Проделывая эту работу вы так или иначе придете к решению аналогичному XML.

Описание протокола данных для передачи и проверка валидности этого протокола.


 
oxffff ©   (2009-04-10 00:29) [37]

to sniknik.

Таким образом XML позволяет задать язык обмена данными между клиентами. И автоматизировать возможность проверки лексической и синтаксической корректности данного языка (протокола).

XML имеет отношение не к саммим данным, а к протоколу обмена данными.


 
sniknik ©   (2009-04-10 00:34) [38]

> А никак (ну конечно же есть частные способы, но нет универсального).
> Далее продолжим.
о чем? ты сам оговорился, в мою поддержку... осталось только перенести это утверждение от притянутого за уши exe файла к обсуждаемому xml-ю, и мы вместе "заборем" ложных пророков с их знаменем "реальной универсальностью" -

DVM ©   (09.04.09 21:29) [12]
>> вот не было бы ажиотажа с этой мнимой универсальностью
> Да она не мнимая, она реальная,

против которых я пока выступал в одиночку... :))

---------------------------
.... доктор, вы либо туда, либо сюда, а вот это туда сюда меня раздражает! © известный анекдот.

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


 
oxffff ©   (2009-04-10 00:37) [39]

to sniknik.

Обобщаю описаннный процесс [34], [36], [37].

Разработка формата включает.

1. Определение формата передаваемых данных.
2. Написание процедур проверяющих валидность переданной информации.
  Проверка синтаксиса переданных данных
3. Проверка семантики переданных данных.
4. обработка данных

Пункт 1 и 2 являются общими для всех форматов.
3,4 имеют значение только в рамках этих данных.

XML берет на себя автоматизацию 1 и 2.
Есть конечно и неприятные минусы. НО!!!
Они вытекают как раз из стремления обобщить процесс 1 и 2.


 
oxffff ©   (2009-04-10 00:40) [40]


> sniknik ©   (10.04.09 00:34) [38]
> > А никак (ну конечно же есть частные способы, но нет универсального).
>
> > Далее продолжим.
> о чем? ты сам оговорился, в мою поддержку... осталось только
> перенести это утверждение от притянутого за уши exe файла
> к обсуждаемому xml-ю, и мы вместе "заборем" ложных пророков
> с их знаменем "реальной универсальностью" -


Речь шла конкретно о двоичном формате EXE файла или любом формате значений (без параметров).


 
oxffff ©   (2009-04-10 00:43) [41]


> sniknik ©   (10.04.09 00:34) [38]


не следует выдирать смысл только из [34].
Смысл для вас станет понятен в цепочке постов
[34],[35],[36] или
кратко в [37]
менее кратко [39]


 
oxffff ©   (2009-04-10 00:56) [42]


> sniknik ©   (10.04.09 00:34) [38]
> > А никак (ну конечно же есть частные способы, но нет универсального).
>
> > Далее продолжим.
> о чем? ты сам оговорился, в мою поддержку... осталось только
> перенести это утверждение от притянутого за уши exe файла
> к обсуждаемому xml-ю, и мы вместе "заборем" ложных пророков
> с их знаменем "реальной универсальностью"


Ну если вы намеренно пропускаете (игнорируте) выделенное

А никак (ну конечно же есть частные способы, но нет универсального). Сложность в том, что значения полей подразумеваются быть на данном месте по определенному абсолютному или относительному смещению от начала файла. То есть по факту есть просто файл значений. Но нет соответствия параметр - значение. Далее продолжим.

То это говорит это том, что вы выдете то, что хотите видеть.
А тот ложный пророк это вы и есть. :)


 
sniknik ©   (2009-04-10 01:02) [43]

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

> to sniknik.
> Обобщаю описаннный процесс [34], [36], [37].
хоть наобобщайся, только ответь конкретно - он универсальный?

> Пункт 1 и 2 являются общими для всех форматов.
> 3,4 имеют значение только в рамках этих данных.
когда работаешь с sql - сервером ты разрабатываешь свой формат? выбираешь универсальный xml? что то другое?
нет! тебе просто дают данные в естественном для сервера формате, - рекордсете, и ты работаешь с ними в том самом естественном для него формате. и это плохо?
из твоих 4-х пунктов первые 3 напрочь откидываются, это он реализует сам, тебе остается только 4 - обработка данных.

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


 
Германн ©   (2009-04-10 01:05) [44]

Мои программы не "поддерживают". И я счастлив этим!
:)


 
sniknik ©   (2009-04-10 01:07) [45]

> Смысл для вас станет понятен в цепочке постов
:о)))
это ты себе льстиш. читаю и вижу бред. а как хорошо обещал в начале, показать все на примерах... не надо было чай пить. вах.


 
sniknik ©   (2009-04-10 01:10) [46]

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


 
oxffff ©   (2009-04-10 01:15) [47]


> sniknik ©   (10.04.09 01:02) [43]


Об универсально XML можно почитать в wiki. Ссылку привеcти?
Он позволяет за вас сделать парсинг файла и проверку его синтаксиса в соответствиии в протоколом в метаописании.
Хотите сказать что вы напишите в два счета формат обладающим тем же свойством?

Далее.

Зачем вы пытаетесь использовать XML там где он не нужен.
Кто вам сказал что так нужно делать?

Он нужен так где формата еще нет, и существующие форматы не обеспечивают полную интероперабельность между всеми клиентами.

Например RPС где то может отсутствовать или быть отключено.
И тут вам придется делать маршалинг и передачу с проверкой в виде файликов.


 
Германн ©   (2009-04-10 01:18) [48]


> sniknik ©   (10.04.09 01:10) [46]

Сочувствую.
Но зато твоя зарплата наверняка гораздо выше моей. :)
А жить за счёт халтурок гораздо сложней, чем "поддерживать" :)


 
oxffff ©   (2009-04-10 01:18) [49]


> sniknik ©   (10.04.09 01:07) [45]
> > Смысл для вас станет понятен в цепочке постов
> :о)))
> это ты себе льстиш. читаю и вижу бред. а как хорошо обещал
> в начале, показать все на примерах... не надо было чай пить.
>  вах.


Повторяю если для вас выделенное отсутствует.

А никак (ну конечно же есть частные способы, но нет универсального). Сложность в том, что значения полей подразумеваются быть на данном месте по определенному абсолютному или относительному смещению от начала файла. То есть по факту есть просто файл значений. Но нет соответствия параметр - значение. Далее продолжим.

То как мне общаться с человеком,  у которого буфер для предложения слишком мал. И информация режется спонтанно.
Может пора и вам чаю принять.


 
Германн ©   (2009-04-10 01:20) [50]


> oxffff ©   (10.04.09 01:15) [47]
>
>
> > sniknik ©   (10.04.09 01:02) [43]
>
>
> Об универсально XML можно почитать в wiki.

В "wiki" можно столько всего разного прочитать, что лучше не читать её вообще!


 
sniknik ©   (2009-04-10 01:22) [51]

Ping-Pong   (09.04.09 22:50) [19]
>>iZEN   (09.04.09 22:38) [18] Сам контент в JSON гораздо компактнее и человекочитабельнее.
> Ну и нафига эта читабельность?
не нужна, но то что он компактнее разве ничего не дает?
кстати еще одно преимущество, при передаче его в яваскрипт (бывает нужда если с сервера данные передаешь)  он одним мановением руки (eval)  превращается в объект, к которому(/данным) дальше обращаешься по именованным полям. удобно. (и поддерживает меня в стремлении обмениваться по возможности "естественными" структурами ;). с xml-ем там мороки гораздо больше. хотя конечно ничего не возможного.


 
sniknik ©   (2009-04-10 01:26) [52]

> Зачем вы пытаетесь использовать XML там где он не нужен.
меня заставляют!!! аааааа :"(

> Кто вам сказал что так нужно делать?
начальство будь оно не ладно...

ты вообще читал что я пишу, прежде чем лезть "образовывать". образователь ты наш. %)


 
oxffff ©   (2009-04-10 01:31) [53]


> sniknik ©   (10.04.09 01:26)
>
> ты вообще читал что я пишу


Читал. Привожу ваш пост [11]


> ненавижу xml...


 
sniknik ©   (2009-04-10 01:34) [54]

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

(понятно думаю о ком? не буду показывать пальцем но это о слонике ;)


 
sniknik ©   (2009-04-10 01:36) [55]

> Читал. Привожу ваш пост [11]
>> ненавижу xml...
и что ты понял? я разве написал "не понимаю xml"?


 
oxffff ©   (2009-04-10 01:42) [56]


> sniknik ©   (10.04.09 01:26) [52]


Например для SAP R3 очень распространено понятие интерфейса для обмена с историческими системами. Это просто текстовый файл значенией.
А вот XML бы там не помешал, поскольку присылаю спецификацию на такой файлик. Начинаешь его обрабатывать, и начинаются грабли. Ребята без уведомления внесли изменения в формат и теперь вместо . , или еще какая нибудь ....
И сидишь в блокноте ищешь где эта несовместимость

Поэтому поскольку данные загоняются в СУБД.
А доступ напрямую к СУБД R3 закрыт.
И к нашим серверам СУБД тоже.

Я просто создаю табличку нужного формата. Далее написал программу. Указываешь файл, СУБД, таблицу и маппинг поля таблицы на колонки в файле.
Она берет значение из файла, берет метаинформацию о столцах таблицы конретно тип колонки таблицы и пытается к нему преобразовать. А я по исключению ловлю эти косяки. Вот так работают в России.
И я так вынужден работать.


 
oxffff ©   (2009-04-10 01:43) [57]


> поскольку присылаю спецификацию на такой файлик

нам  присылают


 
Игорь Шевченко ©   (2009-04-10 01:47) [58]

Не понимаю причин для спора. XML - удобный самоописательный (более или менее) формат для представления структурированной информации, а поддерживать в своих программах работу с них - ну это личное дело каждого или его начальства :)

У нас практикуется обмен данными в XML, схема тегов согласнована с обменивающимися сторонами, это лучше, чем писать десять тысяч импортов в форматах "кто что напридумывает" (а всяческие международные организации мастера придумывать и оформлять свои придумки в виде толстых сброшюрованных документов, которые читать получается только методом Random Access) и двадцать тысяч экспортов.


 
oxffff ©   (2009-04-10 01:50) [59]


> sniknik ©   (10.04.09 01:34) [54]


Ну если для вас ненавижу начальников = ненавижу XML.
Тогда не забывайте об декларировать,

Не любит - значит не принимает.

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


 
oxffff ©   (2009-04-10 01:51) [60]


> Игорь Шевченко ©   (10.04.09 01:47) [58]
> У нас практикуется обмен данными в XML, схема тегов согласнована
> с обменивающимися сторонами, это лучше, чем писать десять
> тысяч импортов в форматах "кто что напридумывает" (а всяческие
> международные организации мастера придумывать и оформлять
> свои придумки в виде толстых сброшюрованных документов,
> которые читать получается только методом Random Access)
> и двадцать тысяч экспортов.


+1.


 
Германн ©   (2009-04-10 01:51) [61]


> Игорь Шевченко ©   (10.04.09 01:47) [58]
>
> Не понимаю причин для спора. XML - удобный

А кто тут понимает "причины для спора"?
А спор-то об чём?
Ты сабж вспомни!


 
Игорь Шевченко ©   (2009-04-10 01:57) [62]

У XML есть много полезных свойств, но еще одно - это то, что яблоки с вагонами можно сопрягать без особых затрат - с помощью XSLT


 
sniknik ©   (2009-04-10 01:58) [63]

> А вот XML бы там не помешал
> Ребята без уведомления внесли изменения в формат и теперь вместо . , или еще какая нибудь ....
допустим настало твое счастье, и там вдруг стал XML, и ребята без уведомления внесли изменения в формат и вместо атрибута с именем Date стали ставить имя Dat...
и чем это будет отличаться?

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

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


 
Игорь Шевченко ©   (2009-04-10 02:02) [64]

Германн ©   (10.04.09 01:51) [61]


> Ты сабж вспомни!


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

У нас, кстати, написано довольно много конверторов из тех самых проприетарных форматов в XML, который мы умеем. Плюсов много, но еще один - это тот, что не надо тратить силы на валидацию входных данных - после тупого формирования XML его можно провалидировать стандартными средствами.


 
Игорь Шевченко ©   (2009-04-10 02:04) [65]

sniknik ©   (10.04.09 01:58) [63]


> допустим настало твое счастье, и там вдруг стал XML, и ребята
> без уведомления внесли изменения в формат и вместо атрибута
> с именем Date стали ставить имя Dat...
> и чем это будет отличаться?


Стандартная(!) валидация не выполнится.

Я напомню, что для работы с XML написана масса средств, в том числе абсолютно бесплатных, с довольно широкой функциональностью, которую массу в противном случае пришлось бы в ряде случаев писать самому, да еще и с ошибками.


 
sniknik ©   (2009-04-10 02:08) [66]

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

так в чем разница то?


 
oxffff ©   (2009-04-10 02:13) [67]


> sniknik ©   (10.04.09 01:58) [63]
> > А вот XML бы там не помешал
> > Ребята без уведомления внесли изменения в формат и теперь
> вместо . , или еще какая нибудь ....
> допустим настало твое счастье, и там вдруг стал XML, и ребята
> без уведомления внесли изменения в формат и вместо атрибута
> с именем Date стали ставить имя Dat...
> и чем это будет отличаться?


Будет отличаться тем, что за меня наличие ошибки в переданном формате найдет XML обработчик в соответствии в выбранной схемой. И укажет мне ее.


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


Именно так и делалось. В блокноте я потом правил на нужное.
Проблема в том, что процесс парсинга совмещен с процессом проверки.
Что требует на каждый формат, свой парсер с анализатором типов.
Раньне так было. А сейчас раздельно и независимо.


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


Я бы вообще от R3 отказался. Но я не бог.


 
sniknik ©   (2009-04-10 02:16) [68]

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

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


 
Германн ©   (2009-04-10 02:18) [69]

Игорь Шевченко ©   (10.04.09 02:02) [64]
>
> Германн ©   (10.04.09 01:51) [61]
>
>
> > Ты сабж вспомни!
>
>
> А вполне кстати разумный сабж

Ну тебе наверно видней. :)


 
oxffff ©   (2009-04-10 02:19) [70]


> sniknik ©   (10.04.09 02:08) [66]
> > Стандартная(!) валидация не выполнится.
> от того, что в числе вдруг стали точку вместо запятой давать,
>  стандартное(!) преобразование даст эксепт.
>
> так в чем разница то?


Разница в том, что на процесс метаописания в одном случае задается в виде текстового файла, а в другом программируется.
Например было 20 полей. Стало 120.
В текстовом файле описал структуру, тип.

Далее программно описываешь тоже самое + код на каждое поле по генерации исключения.


 
oxffff ©   (2009-04-10 02:24) [71]


> sniknik ©   (10.04.09 02:16) [68]
> повторю приведенный уже в начале пример, для меня чаще всего
> обмен идет mssql-ными базами (я их тестирую) на вход желаю
> получать стандартный бэкап... уменьшит ли проблем если я
> стану получать базы в xml-е?


преобразование в универсальный формат и обратное преобразование в родной в данном конкретном случае - это лишнее.


 
Игорь Шевченко ©   (2009-04-10 02:29) [72]

sniknik ©   (10.04.09 02:16) [68]


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


Увеличит.

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

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

XML-формат тоже приносит пользу при тех же условиях употребления.


 
sniknik ©   (2009-04-10 02:30) [73]

> преобразование в универсальный формат и обратное преобразование в родной в данном конкретном случае - это лишнее.
молодца.
берем второй пример с таблицами/данными в рекодсетах которыми с нами обменивается sql - сервер. тут?

p.s. чувствую еще немного, и совращу тебя в свою веру. но чето спать клонит. оставайся не совращенный.


 
sniknik ©   (2009-04-10 02:34) [74]

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


 
Игорь Шевченко ©   (2009-04-10 02:37) [75]

sniknik ©   (10.04.09 02:34) [74]


>  суть то моих претензий именно в том, что вынуждают применять
> где ни попадя


Что, и при передаче бэкапов баз mssql вынуждают XML применять ?

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


 
oxffff ©   (2009-04-10 02:45) [76]


> sniknik ©   (10.04.09 02:30) [73]
> > преобразование в универсальный формат и обратное преобразование
> в родной в данном конкретном случае - это лишнее.
> молодца.
> берем второй пример с таблицами/данными в рекодсетах которыми
> с нами обменивается sql - сервер. тут?


А тут ответа одназначного нет. И быть не может.

причины:

1.. Все данные обрабатываются через сервер приложений. И никто вам не даст просто то так закатать raw данные без предобработки. Насколько будет безопасно такое обновление данных минуя логику.
2. Технологии доступа к данным в большинстве своей основаны на использовании RPC. Что делать если он отлючен?


> p.s. чувствую еще немного, и совращу тебя в свою веру.


А я гляжу вы еще тот шалун.

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


 
Городской Шаман   (2009-04-10 03:12) [77]


> sniknik ©   (10.04.09 01:02) [43]


Не умеете вы говорить с менеджерами. Хоть бы книжки почитали. Начинать надо было с синхронизации семантического определения слов и их определений.

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

Если бы вы всё так красиво расписали, то и проблем бы не было и xml бы полюбили.


 
Sergey Masloff   (2009-04-10 04:42) [78]

sniknik ©   (10.04.09 02:08) [66]
>> Стандартная(!) валидация не выполнится.
>от того, что в числе вдруг стали точку вместо запятой давать, стандартное>(!) преобразование даст эксепт.

>так в чем разница то?

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


 
TUser ©   (2009-04-10 07:55) [79]

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


 
Медвежонок Пятачок ©   (2009-04-10 09:10) [80]

так как в гомогенной среде вопрос об формате данных не стоит, а стоит вопрос об их удобном представлении для обработки (бинарный вид).

удобное проедставление в том числе для удобной обработки очень хорошо вяжется с xml


 
Rouse_ ©   (2009-04-10 09:17) [81]

ХМL очень удобная чтука, особенно когда отбрыкиваешся от клиентов которые хотят чтобы мы за собственные деньги состыковали выходные данные нашего ПО с ихними программными комплексами :)

ХML получили? Описание его получили? Вот и... "занимайтесь с ним любовью" :)


 
Медвежонок Пятачок ©   (2009-04-10 09:19) [82]

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


 
Медвежонок Пятачок ©   (2009-04-10 09:20) [83]

последний пост - это про "ненужность" xml в гомогенной среде.


 
sniknik ©   (2009-04-10 09:36) [84]

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

> причины:
> 1. .....
> 2. .....
аааааа...., это ты о чем? кто мне не даст в своем приложении? при чем тут безопасность. аааааа... извини но я устал читать твою чушь. проще наверное игнорировать.

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

> А в случае с XML они и сами проверят валидность и супротив стандарта не попрешь.
в случае обмена таблицами (тем же dbf. который предлагался, в отличие от самопального на который просто был ответ из-за сравнений с ним) тоже есть проверка валидности, и числа туда нормально попадают читаются движок заботится. и... ???
вот у нас 1C-совцы, обменивались dbf-ами (другим не могли) и были счастливы, после пришла 8-ка, и тут же "нам нужен xml", ну им там просто (огда механизм предоставили), нужно сделали, и скорость обмена (приема данных) упала в 3 раза. сказали "фигня, зато поддержка модного формата, а обмен должен делаться маленькими порциями, не заметно". но только "тупые" юзеры нифига не понимают, видят "выгрузка" и жмут выгрузить весь справочник т.к. на новую установку им его весь необходим. а там в зависимости от размера скорость падает по экспоненте, до полного ступора... ладно, сделали ограничители количества (то ли 5 то ли 50 тыс, а обычно справочник товаров = 80-130 тыс), теперь справочники переносят кусками... и все "счастливы", ну кроме тех юзеров, что помнят насколько проще было с dbf.  и кому это было нужно? если и так все работало.
а счас на "подходе", планируется 3-е изменение, суть так и делить на куски но скрыто от юзера, паковать куски и давать ему зип архив, чтобы одним файлом, на другой стороне обратные действия...
и никто не хочет признать, что его внедрение только добавило проблем, откатится на старое и все. нет, т.к. это первое потеря "модного формата" нельзя будет говорить, что поддерживаем, признание, что были идиотами когда не слушали техников (про "ситуацию" предупреждали заранее), ну и они постоянно "решают проблемы по мере поступления", допускаю что просто не помнят о чемто другом кроме того что перед носом, отсюда и такие неуклюжие, громоздкие решения.
да и насчет очевидного "а дайте им выбор xml/dbf", нельзя, юзер он же "тупой", не нужно ему давать ветвления для однозначных действий, это его сбивает. (слова начальства, и вот кстати тут, я его поддерживаю, ибо разумно).  

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


 
Медвежонок Пятачок ©   (2009-04-10 09:44) [85]

в случае обмена таблицами (тем же dbf.

с ним далеко не все в шоколаде.


 
Игорь Шевченко ©   (2009-04-10 11:27) [86]

sniknik ©   (10.04.09 09:36) [84]

Формат не только модный, но еще и удобный. Впрочем, никто не запрещает обмениваться и dbf и бэкапами баз mssql, просто это не недостаток XML, что "юзеры жмут выгрузить все"...


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [87]

> sniknik  (09.04.2009 23:38:30)  [30]

И проблемы, как минимум по ресурсам.
Я уже расказывал, но еще раз повторю, как мы переносили базу с dbf на MS SQL.
Сначала по рекомендации запустили экспорт в формате XML, спустя неделю аварийно сняли процесс, надоело ждать, по оценке, за это время, было выполнено всего 30%.
Затем запустили не рекомендованый путь, через DBF - спустя 1.5 часа наслаждались результатом.
Прямо перегонять с помощью запросов нельзя, множество преобразований и проверок, иначе бы всего несколько INSERT INTO.


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [88]

> Хитрий Лис  (10.04.2009 0:19:35)  [35]

Вот когда кормить будут, тогда да, но пока насилуют.E5ще раз повторю, как мы переносили базу с dbf на MS SQL.
Сначала по рекомендации запустили экспорт в формате XML, спустя неделю аварийно сняли процесс, надоело ждать, по оценке, за это время, было выполнено всего 30%.
Затем запустили не рекомендованый путь, через DBF - спустя 1.5 часа наслаждались результатом.
Прямо перегонять с помощью запросов нельзя, множество преобразований и проверок, иначе бы всего несколько INSERT INTO.


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [89]

> oxffff  (10.04.2009 0:24:36)  [36]

Скажем между DBF и XML по этой части практически нет никакой разницы, кроме огромного оверхеда и плюса при передаче по сетям - текстовый формат, не надо упаковывать и/или передавать как вложение, в случае почты, но это плюс призрачный. Это по формату, а по времени обработки и ресурсам смотри предыдущее сообщение.0через DBF - спустя 1.5 часа наслаждались результатом.
Прямо перегонять с помощью запросов нельзя, множество преобразований и проверок, иначе бы всего несколько INSERT INTO.


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [90]

> oxffff  (10.04.2009 0:56:42)  [42]

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

Для баз данных это не так, только начинающие или недостаточно квалифицированые работники опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

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


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [91]

> sniknik  (10.04.2009 1:26:52)  [52]

Очень нравится, когда ни с того ни с сего госорган присылают отчет в виде XML файла и пользователи думают что же с этой абракадаброй делать, а открывается он в Экселе. Никакой поддержки от госоргана получено не было. Звонить также бессмысленно.опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

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


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [92]

> Игорь Шевченко  (10.04.2009 2:29:12)  [72]

Игорь так тема то о том, об универсальности и применяемости везде. С этого начиналось, это и развенчивается, что не надо применять всегда и везде. И что область применения много меньше.E0 получено не было. Звонить также бессмысленно.опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

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


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [93]

> sniknik  (10.04.2009 2:34:14)  [74]

Если бы только поставить галочку.2ом, об универсальности и применяемости везде. С этого начиналось, это и развенчивается, что не надо применять всегда и везде. И что область применения много меньше.E0 получено не было. Звонить также бессмысленно.опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

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


 
Anatoly Podgoretsky ©   (2009-04-10 12:04) [94]

> Rouse_  (10.04.2009 9:17:21)  [81]

> ХML получили? Описание его получили? Вот и... "занимайтесь с ним любовью" :)

Правильнее так

ХML получили? Вот и... "занимайтесь с ним любовью" :)

Он же самодокументированый :-)

И именно с такими ситуациями я и сталкивался в основном, и при том с обязательностью обработки, иначе до 7 лет.
Ну ладно я справлюсь, а что делать рядовым пользователям?
При наличии только таких средств как Эксель, ИЕ2ид и данных и метаданных. Нет преимуществ, куча недостатков.

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


 
app ©   (2009-04-10 12:05) [95]

> oxffff  (10.04.2009 1:18:49)  [49]

Давай без наездов, сдерживайся. А то ты уже несколько раз подряд успел оскорбить на ровном месте.
Тоже к остальным участникам.


 
app ©   (2009-04-10 12:05) [96]

Удалено модератором


 
sniknik ©   (2009-04-10 12:32) [97]

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

Anatoly Podgoretsky ©   (10.04.09 12:04) [87]
фух, ну хоть еще один понимающий, гора с плеч... я уж начинал думать, что я один такой. :))

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

> XML удобен для иерархических данных, например меню, файловые системы и подобное.
:) а "сторонники", почему то ни одного примера нормального выдать не могли, только обещали, кроме того, что им удобно настройки иерархические хранить...

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


 
DVM ©   (2009-04-10 12:43) [98]


> sniknik ©   (10.04.09 12:32) [97]


> фух, ну хоть еще один понимающий, гора с плеч... я уж начинал
> думать, что я один такой. :))

Не один :) Мы с тобой! :)


 
Palladin ©   (2009-04-10 12:45) [99]


> sniknik ©   (10.04.09 12:32) [97]
> фух, ну хоть еще один понимающий, гора с плеч...

Ну почему один. Я тоже понимающий. Просто, молчу сижу... :)


 
Медвежонок Пятачок ©   (2009-04-10 12:54) [100]

кусок примочки к одному популярному авиасимулятору
http://il2sc-cherep.narod.ru/demo/demo_history.html


 
DVM ©   (2009-04-10 12:55) [101]


> sniknik ©   (10.04.09 00:34) [38]
>

> DVM ©   (09.04.09 21:29) [12]
> >> вот не было бы ажиотажа с этой мнимой универсальностью
> > Да она не мнимая, она реальная,
>
> против которых я пока выступал в одиночку... :))
>
> ---------------------------
> .... доктор, вы либо туда, либо сюда, а вот это туда сюда
> меня раздражает! © известный анекдот.
>
> ты это, определись, он все таки универсальный или нет, и
> в каком смысле. и если нет, т.е. я прав окончательно и безоговорочно,
>  то кто кого учить должен? и причем тут "для чего он нужен"?
>  разве от этого сакраментального знания он станет более
> универсальным? что за подмена понятий?


Я убежден, что XML универсальный язык для описания всего чего угодно. Универсальней его только SGML. Он действительно может быть применен где угодно, но расплата за универсальность - гигантская избыточность.

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


 
Медвежонок Пятачок ©   (2009-04-10 12:57) [102]

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

а вознаграждение - чудовищно гигантская гибкость.


 
Anatoly Podgoretsky ©   (2009-04-10 13:01) [103]

В кустах сидят, отмалчиваются :-)

ЗЫ: некоторые непонятки в сообщениях, это артефакты от других сообщений, форум висел, а у меня ошибка где-то в сервере. И при массовой отсылки получаются артефакты.


 
Игорь Шевченко ©   (2009-04-10 13:07) [104]

Anatoly Podgoretsky ©   (10.04.09 12:04) [92]


> Игорь так тема то о том, об универсальности и применяемости
> везде. С этого начиналось, это и развенчивается, что не
> надо применять всегда и везде


дай дураку член стеклянный он и руки порежет и член разобьёт :)

Я уже говорил, что XML, как и любое другое средство приносит пользу, будучи употреблено надлежащим образом в надлежащее время. В частности, возможность его валидации стандартными средствами - очень большое преимущество перед другими форматам обмена данными, точно также возможность использования старых программ при расширении состава данных (введения новых тегов) тоже является преимуществом.
А то, что он более объемный по сравнению с plain-текст, например - это недостаток. Тут важно решить, что перевешивает, сумма недостатков или преимуществ.


 
sniknik ©   (2009-04-10 13:30) [105]

> Я убежден, что XML универсальный язык для описания всего чего угодно.
т.е. ты за вариант (я там 2 предлагал) понимать универсальность как "в него вы можете впихнуть все что угодно и как вам угодно", а не второго типа "посылайте его куда хотите его везде поймут"...
логично.
проблема только в том, что в массы "подают" вторую интерпретацию, и здесь в этой ветке, если присмотреться она тоже присутствует, даже превалирует.
хотя из первого вовсе не следует второе, даже наоборот, чем большими возможностями универсальности "первого типа" кто то воспользуется для создания обмена, тем труднее его будет прочитать другой стороне, т.е. это сразу минус от универсальности "второго типа"...
для "второго типа" самыми универсальными будут "жесткие" структуры, попросту не допускающие в себе интерпретаций данных по типам/местоположению и т.д. чем ограниченней тем лучше. типа например таблиц... ну, логично же! как этого не понимают, не пойму.


 
Игорь Шевченко ©   (2009-04-10 13:54) [106]

Кстати, об обмене данными, совершенно реальные ситуации.

Имеется схема (порядка сотни таблиц) с данными, где-то на полгигабайта.
Схема живет в Oracle 9, кодировка базы данных CL8MSWIN1251
Все данные крайне желательно перетащить в Oracle XE Universal (кодировка базы данных AL32UTF8 (Юникод, если что)). Стандартный import/export в этой ситуации не годится, так как ANSI-данные в Unicode увы, не переносятся, если они русские.

Имеется схема (порядка сотни таблиц) с данными, где-то на полтора гигагбайта. Схема живет в Interbase(Firebird).
Все данные крайне желательно перетащить в Oracle XE тот же, что и в предыдущем примере.

Кто-нибудь подскажет способ, кроме преобразования в XML в исходной базе и импорт XML в принимающей ?


 
sniknik ©   (2009-04-10 14:09) [107]

> Кто-нибудь подскажет способ
ADO и его рекордсеты... OLEDB провадеры есть на обоих, из одного делаешь запрос и сохраняешь рекордсет (SaveToFile)  в формате pfADTG (pfXML гораздо более ресурсоемкий), у другого загружаешь сохраненный рекордсет "бежиш" по нему, и инсертишь данные через ADOCommand.
Unicode ADO/сами рекордсеты поддерживают, главное в дельфи их не "запороть" (или взять 2009й).


 
Игорь Шевченко ©   (2009-04-10 14:28) [108]

sniknik ©   (10.04.09 14:09) [107]

Программу писать на каждый чих ? Нет, спасибо, способ не годится. Кроме того, ADO ломается на объемах в миллионы записей - уже испытано.

Delphi 2009 я покупать не хочу.


 
oxffff ©   (2009-04-10 14:36) [109]


> Anatoly Podgoretsky ©   (10.04.09 12:04) [89]
> > oxffff  (10.04.2009 0:24:36)  [36]
>
> Скажем между DBF и XML по этой части практически нет никакой
> разницы,


Ого. Как завернули.


 
oxffff ©   (2009-04-10 14:39) [110]


> Anatoly Podgoretsky ©   (10.04.09 12:04) [90]
> > oxffff  (10.04.2009 0:56:42)  [42]
>
> > Сложность в том, что значения полей подразумеваются быть
> на данном месте по определенному абсолютному или относительному
> смещению от начала файла.
>
> Для баз данных это не так, только начинающие или недостаточно
> квалифицированые работники опираются на или относительному
> смещению от начала файла. Остальные работают с именами или
> метаданными.


Если вы не поняли контекста, то не следует выдирать предложения из него и переиначивать на свой лад.


 
oxffff ©   (2009-04-10 14:46) [111]

Удалено модератором
Примечание: Обсуждение модерирования


 
oxffff ©   (2009-04-10 15:03) [112]

Всем кто пытается провивопоставить DBF XML.
XML и DBF нельзя сравнивать.
Поскольку одно из них средство для определения формата и возможностью универсальной проверки его действительности.
А второе это сам формат.


 
sniknik ©   (2009-04-10 15:05) [113]

> Программу писать на каждый чих ?
зачем на каждый? один раз. экспорт/импорт в xml тоже же кто то писал прежде чем его можно стало использовать.

> ADO ломается на объемах в миллионы записей - уже испытано.
ну, не знаю, переубеждать не буду но я пробовал миллионы (даже вроде 5ть) и вроде все "жило". тут скорее не от количества записей, а от их объема зависит. рекордсет это все таки данные в памяти. естественно он ей и ограничен.

> Delphi 2009 я покупать не хочу.
не обязательно, главное не пользоваться дельфевскими строками, не отображать и читать после в интерфейсе, сам по себе дельфи как язык то юникод поддерживает, проблема у него с ним в VCL. (на D7 точно нормально можно работать с юникодом/передавать данные. пробовал)


 
sniknik ©   (2009-04-10 15:09) [114]

> Вот дела значит последнее предположение из поста мы игнорируем.
> sniknik ©   (10.04.09 01:07) [45]
там нет оскорбления, там сказано что ты пишешь бред, что есть факт. каждый может прочитать выше и убедиться.


 
Игорь Шевченко ©   (2009-04-10 15:14) [115]

sniknik ©   (10.04.09 15:05) [113]

эскпорт из оракла в xml можно найти в готовых инструментах. Импорт тоже


 
Игорь Шевченко ©   (2009-04-10 15:15) [116]

sniknik ©   (10.04.09 15:05) [113]

а вот из Interbase так и не вышло, пришлось программу писать, да не простую, а с вывертами


 
oxffff ©   (2009-04-10 15:19) [117]


> sniknik ©   (10.04.09 15:09) [114]
> > Вот дела значит последнее предположение из поста мы игнорируем.
>
> > sniknik ©   (10.04.09 01:07) [45]
> там нет оскорбления, там сказано что ты пишешь бред, что
> есть факт. каждый может прочитать выше и убедиться.


Напоминаю что вы из трех моих предложений, выбросили одно.
И на основании этого делаете выводы.
Это бред. Так устроет?


 
Городской Шаман   (2009-04-10 15:50) [118]


> Медвежонок Пятачок ©   (10.04.09 09:10) [80]
>
> так как в гомогенной среде вопрос об формате данных не стоит,
>  а стоит вопрос об их удобном представлении для обработки
> (бинарный вид).
>
> удобное проедставление в том числе для удобной обработки
> очень хорошо вяжется с xml


Угу, только если в процедуру передавать не бинарный массив, а xml, который нужно сперва распарсить а потом уже обрабатывать, то скорость упадет на пару порядков.

А с бинарными данными возможна квантовая оптимизация рабочего кода, когда вычисление идёт фактически быстрее скорости света (пример - бинарный поиск или хеширование данных).


 
Городской Шаман   (2009-04-10 16:00) [119]


> sniknik ©   (10.04.09 09:36) [84]


Я бы сделал так, точнее я так и сделал - пакет данных представляет собой zip-файл в котором в корне лежит data.xml. В нем прописываются примитивные данные типа версии и прочем. Есть данные бинарные(типизированные или нет), где в самом xml прописан путь к ним внутри bin-файла. Так вот binary движком автоматически загоняются в zip файл папку bin и ссылка на них идёт в data.xml. А небольшое количество данных примитивных типов для обработки этих binary лежит в самом xml.

Тоесть вышел из воды с/ухой, когда и скорость и xml.


 
Ega23 ©   (2009-04-10 16:32) [120]


> вычисление идёт фактически быстрее скорости света


Я бы не стал заходить так далеко и на константы замахиваться.


 
sniknik ©   (2009-04-10 17:12) [121]

> Я бы сделал так, точнее я так и сделал -  .....
ну наверное и нас что то похожее будет, я этим не занимаюсь т.что как 1с-ники сделают так и ладно.

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


 
Ega23 ©   (2009-04-10 17:26) [122]

Дебильная ветка какая-то...


 
Городской Шаман   (2009-04-10 17:33) [123]


> sniknik ©   (10.04.09 17:12) [121]
>
> > Тоесть вышел из воды с/ухой, когда и скорость и xml.
> вот вот, xml настолько "вьелась", что "кровь из носу но
> должна быть", так? :)


Нет, мое решение я сам принимал. Так как zip-овать все рано нужно, а xml уж очень удобная структура для описания метаданных для обработки данных которые лежать в той же самой структуре - zip-файле.

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

Совмещается удобство XML и скорость обработки бинарных данных.

PS
Эх. Приняли бы это за стандарт "xml-бинарное хранилище данных" то и проблем бы не было ни у менеджеров, ни у программистов.


 
Медвежонок Пятачок ©   (2009-04-10 17:33) [124]

Угу, только если в процедуру передавать не бинарный массив, а xml, который нужно сперва распарсить а потом уже обрабатывать, то скорость упадет на пару порядков.

Распарсить, распарсить.....
Да все уже распаршено
А в процедуру передается не xml (здесь текст что ли подразумевается?), а ixmldomnode,ixmldomnodelist, или сам документ.

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


 
Городской Шаман   (2009-04-10 17:36) [125]


> Медвежонок Пятачок ©   (10.04.09 17:33) [124]


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


 
Медвежонок Пятачок ©   (2009-04-10 17:36) [126]

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

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


 
Медвежонок Пятачок ©   (2009-04-10 17:39) [127]

Ну дык в данном случае вы работаете уже не с xml

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

Мне вообще глубоко филетово что там внутри напёхано.
Я сосредоточен на самих алгоритмах обработки данных.


 
oxffff ©   (2009-04-10 18:03) [128]

To sniknik ©  

Хотелось бы пояснить свою позицию по вопросу XML or DBF.
Я придерживаюсь простой точки зрения и на протяжении всех постов отстаиваю ее. Вот она

При разработке новых форматов при передаче данных одним условием является разработка самого формата(EXE, DBF, MDB, ......), где описано что зачем идет, то есть описана последовательность данных и сам формат данных.

Не менее важным является и процесс написания парсера этого формата и валидатора.  
Написание Парсера и валидатора < - это две стадии, которые присутствуют при разработке всех форматов. Естественно возникает большой соблазн. А почему бы не написать такой универсальный парсер и валидатор, который был бы действителен множества форматов. Однако такой универсализм требует выполненени простого правила процесс задания и описания данных подчиняется правилу задания таких правил и форматов(формату задания этого в XML). Таким образом XML - формат для задания других форматов. То есть это метаформат.
Именно обобщение процесс парсинга и валидации является целью XML.

А когда вы спрашиваете XML или DBF?
Для меня не понятен смысл этого вопроса.

Ответ очевиден. Если есть готовые форматы используйте их.
Но если от вас требуется разработать формат.
Для того чтобы не .... с парсером и валидатором. Имеет смысл использовать обобщенное решение. Это XML или подобные.



Страницы: 1 2 3 4 вся ветка

Форум: "Прочее";
Текущий архив: 2009.06.14;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.92 MB
Время: 0.008 c
2-1240904761
rar
2009-04-28 11:46
2009.06.14
Копирование файла


2-1240598762
buzb
2009-04-24 22:46
2009.06.14
Как разместить компонент над всеми остальными


2-1240130737
Андрей (начинающий)
2009-04-19 12:45
2009.06.14
Удаление записей из связанных таблиц


9-1180293174
man-1982
2007-05-27 23:12
2009.06.14
GLscene динамическое обновление тестур


2-1240669734
snake-as
2009-04-25 18:28
2009.06.14
Остается след от BitMap при движении





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский