Зачем нужен формат XML при обмене #126507

Гопода !Кто нибудь может популярно объяснить, что дает формат XML при обмене, в чем смысл его использования?Зачем все это нагромождение если можно обмениваться через текст, DBF и т.п.

понты + платформенная независимость

А нахрен нам платформенная независимость если 1С пока что только на одной платформе виндовс ?

так XML мутили не для 1с :)Эт 1с просто его юзает

Вот и хочется осознать для чего она его юзает помимо понтов?

DBF - плоская таблица с жесткой структурой, а xml более универсален и гибок. Программы для обработки данных быстрее писать и проще модифицировать.

Для соблюдения стадартов. Так сказать хороший тон. Типа как писать красивый читабельный код.

Я уже как то спрашивал об этом здесь сказали "Дань моде" - на том и порешили!!!

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

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

В 8_0 конкретно продвинулись в плане XML, там при выгрузке/загрузке не важно внутреннее содержание объекта (т.е. все равно выгружать "номенклатура" или "контрагентов") код выгрузки/загрузке разных справочников будет ОДИНАКОВ. В этом я полагаю ГИГАНСКОЕ приемущество перед любым другим форматом обмена т.е. при смене релизов/редакций код обмена менять не надо.

Угу. Хорошая структура. Неиндексированное текстовое дерево. А главное, очень быстрое...

Ты сам ответил на свой вопрос. XML-это формат обмена данными, то есть это стандартизация. Где ты найдешь общепризнанные стандарты обмена данными в формате dbf и txt?Второе: при умелом использовании "Конвертации данных" можно создавать правила обмена гораздо быстрее, чем каждый раз писать одно и то же руками.

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

Для перегрузок я использую только XML! Открыл конвертацию данных, сформировал правила и наслаждайся. Сколько времени уйдет у вас, чтобы написать загрузку с неопределенными поляи синхронизации? К примеру справочник номенклатуры я собираюсь сопоставлять по полям артикул и вид номенклатуры, а справочник материалов: наименование и счет учета. А в выгрузке через XML прописываются поля синхронизации и загружающий модуль делает все сам. Преимуществ море, формат универсален, в один файл впихнуть можно практически любые данные, теги можно делать свои - нет рамок.

"что он закрыт для редактирования (оказывается такая возможность есть у XML текстов)" - БРЕД! Файл XML - обыкновенный текстовый файл. И сам файл правил обычно руками не редактируют (ну если только самые, самые ;-) ).

валидация

16+ to Возможность выбора между DOM API и SAX API

Дык я его не руками пытался править а именно в в "Конвертации" - не сохраняет она мои правки хоть ты ее убей. С нуля да - создает. Звонил на линию консультации - там и сказали, что типа так и должно быть бо стандартные правила обмена закрыты для редактирования.

17+ Это стандарт, который поддерживают все ведущие средства разработки.

Так а причем здесь xml как стандарт?

еще раз БРЕД! Файл XML в конвертации НЕ РЕДАКТИРУЕТСЯ. Это файл является продуктом деятельности этой программы. А чтобы редактировать правила поставляемые вместе с конфигурацией достаточно было в одном месте поставить галку - отключить контроль прав.

txt. - тоже все ведущие поддерживают, да и DBF - тоже,а насчет DOM и SAX попрошу углубить и расширить

Файл правил - он тоже в формате XML - и потому в конвертации должен редактироваться.А про галку это имеется в виду в "КОнвертации" - если можно поподробнее где именно, щас надо будет попробовать.

И где ж эта галка в конфигурации для конвертации?

"XML - язык широко используется в Интернет-технологиях" - приведите хотя-бы десять примеров где это работает.Есть ещё недостаток скорость работы с ним просто убивает.И память загруженный файл жрет в 10!!! раз больше своего объёма, и так не молого по сравнению с txt.

1. Никакокой txt не стандарт. Вот скажи, в каком стандарте описано, какими разделителями должны быть разграничены данные в txt документе: пробелами, запятыми или какими другими кракозябрами? :)   2. А про API я вообще молчу, потому что нет у txt вообще никакого API. Каждый разработчик как хочет, так и разбирает текстовый документ. Это даже в пределах одного предприятия неприемлимо, а не то чтобы в масштабах страны или всей земли...   Все это относится и к ДБФ.

Что-то я тоже не понимаю как это стандарт обмена.Если контрагенты не договорились, а том что значат те или иные поля или теги или строки, то полезную информацию всё равно не извлечёшь. А если договорились, то чем txt не нравиться.

Кр, ты если не знаешь, то лучше бы не говорил, а то только опозоришься. Открывай поисковик какой - нибудь и ищи по ключевым словам: web servises, SOAP, ADO.NET, SQL Server 2005, Oracle, .net. Достаточно?

Да есть у него API - просто он более низкого уровня (ПолучитьСтроку, ЗаписатьСтроку и т.п.)Но ты бы нам лучше про DOM и SAX поведал, что за хрень и зачем она мне вдруг должна быть нужна?

LOL! Может для автоматизации двух пивных ларьков это и стандарт...

учите мат часть.Сервис -> пользователи -> в редактировании элемента -> Отключить контроль

1. это не API2. DOM и SAX - это два разных API. Первый подразумевает полную загрузку докумета в память. Преимущества - обращение к произвольному узлу и не один раз. Недостатки - для больших документов может не хватить памяти. SAX API предполагает последовательный просмотр xml документа. Недостатки - нельзя обратиться к любому узлу, а можно только последовательно просматривать узлы.3. Я еще писал про валидацию. Возможность проверить xml документ на соотвествие xsd схеме - главное преимущество xml перед txt и дбф.

Вы перечилили по существу технологические платформы, я же спрашивал про конечные решения.Какой интернет-магазин от меня примет заказ в XML формате например?

Если я правильно понял то ента валидация позволяет в одном месте изменить файл правил - разослать его по контрагентам и те у себя без перепрограмироания кода смогут читать изменнные файлы данных.Однако как правильно сказал о расшифрове новых тегов всеравно придется договариваться.ДА?

Попробовал я это сделать, В пользователе отключил контроль прав, взял готовые правила конвертации изменил кое что в файле правил нажимаю "Сформировать файл править => переписать целиком", а он мне "Не могу записать файл, неизвестная ошибка"И как с этим бороться?

+34 Причём с моими собственными тегами?А если теги должен определить интернет-магазин, то чем это лучше мне писать свою программу XML, чем в txt.

Любой интернет - магазин, в котором рулят опытные и образованные программисты. Возьми хотя бы 1С Предприятие 8.0 и посмотри, как там организован web доступ.   Доводилось мне как - то одну систему писать, в которой обмен данными организован с помощью txt документов. Какой это головняк: одни организации принимают данные, разделенные запятыми, другие пробелами. У одних сначала идет заголовок, потом определение, у других наоборот. А если бы файл обмена был бы описан с помощью xsd схемы, то проблем вообще никаких не было бы. Я бы просто взял бы этот xsd и выгружал бы данные в соответствии с ним. Более того, если бы мой xml документ не прошел бы валидацию, то он вообще бы не выгрузился. А на другом конце провода прогаммист, который пишет приложение для разбора xml документов тоже проблем не знает: схема все ему подскажет.Кстати говоря: графическое API у винды скоро тоже будет на xml построено: ключевое слово AVALON.

XML - это круто, если, конечно, используешь "Конвертацию данных", тоже, кстати, которую считаю крутой конфой

Я попрасил назвать конкретные магазины 10 штук, или хотя бы 5.И если это действительно "XML - язык широко используется в Интернет-технологиях" то никаких проблем быть не должно.

нет, не правильно Извини, мне пора уходить. Я тебе только одно посоветую: купи какую - нибудь книжку по xml и почитай. Здесь тебе все равно многого не объяснят.

Как так не правильно!Если к тебе пришел файл XML с новым тегом "цена", вместо станого "ЦенаПродаж4Кол". Это как мне понимать эту новую цену? Как продажная цена, оптовая, рекомендуемая заводом, или это вообще артикул товара?

Господа ! Надо бы ответить на

43) Этой ошибки не встречал. Но были и другие. В этом году переносил где-то шесть бугалтерий 432 -> 507. У всех базы типовые, ред. одинаковы. Но почти в каждой следующей правила отказывались работать, выдавая неизвестную ошибку. Приходилось по-новой формировать часть правил.

А зачем вообще заморачиваться при конвертации данных через файлы или "Конвертация данных", не проще ли просто подключиться через OLE Applicatrion и просто скопировать данные...

2 Может, повторюсь, т.к. всю ветку не читал.Для разработчика удобство прежде всего в том, что не нужно писать своё низкоуровневое средство доступа к данным. Работа с XML осуществляется на более высоком уровне, т.к. существующие парсеры предоставляют объекты для удобного доступа к данным (чем сложнее структуры данных, тем очевидней выигрыш). Опять же валидацию самому писать не нужно - она уже есть.Наличие стандарта описания метаданных - бесценная вещь.Т.е. идеи заложенны все очень прогрессивные, но вот реализация...Имело смысл для стандарта передачи данных разработать двоичный компактный и эффективный формат, а не использовать Markup Language. Т.е. публикацию в Web, это, конечно, облегчило на порядок, но вот эффективность самого формата на больших объемах данных оставляет желать лучшего.

Конвертация данных рулита вторая версия КД рулит относительно первой

он же придет к тебе с описанием типа<ОбъектИсточник Тип="Справочник" Вид="ЗначенияСубконто" Уникальность="ВПределахПодчинения" КоличествоУровней="4" />так что ..

Почитав некоторые посты вспоминается преславутое :

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

Насколько я помню, Мелкософт отказался от использования компаундов в Офисе 2005. Теперь документы и электронные таблицы будут сохраняться в XML. Так что технология перспективная.

XML помимо самих данных содержит и описание структуры данных. Отсюда и удобство. Отсюда и его распостаненность. Мода здесь ни при чем

Свой пример в пользу XML. Я года три назад в качестве тестового задания написал обмен данными в формате XML.и вот уже на протяжении трех лет этот обмен работает, за это время я не изменил ни строчки кода в обработку обмена,а конфа часто менялась, например добавлялись новые реквизиты в справочники или документы, при этом загрузка/выгрузка работала даже если в переферийных базах еще не были добавлены эти реквизиты.Вывод граммотно разработанный формат обмена в формате XML снижает стоимость владения системой.А вообще XML это упрощенный вариант SGML, который используется в издательском деле, и создан как альтернатива HTML( но не полная, HTML отвечает за отображение,а XMl структуру данных) ,.Есть веб страницы которые разработаны в XML, но вы видите HTML, т.к перед отправкой документа вам он претерпевает XSL преобразование,(то есть раз и на всегда разработав структуру вашей страницы, можете легко менять ее дизайн, например создав тег <news>, вы можете определит что по четвергам он будет выводиться 2 шрифтом, а по тяпницам 3, при этом не трогая самого документа)

А зачем это надо? Ведь описание структуры все равно приходится согласовывать. Иначе даже прочитав и разобрав по-структурно применить эту инфу не сможем. Это что теперь значит в Опен офисе можно будет документ ворда открыть?

Пример первый - то же самое можно и с txt сделать чтоб грузились те поля (или строки) которые есть в базе, остально без ошибок пропускалось. Чем плохо обмен с банк-клиентами организован в 1С.Второй пример - почти всё хорошо. Только это не обмен данными (универсальный как это декларируется). И быстродействие у сервера должно быть на уровне (причем веб - это МАССОВОЕ обслуживание), чтобы все страницы на лету создавать, а потом уж не так много серверов с оперативной сменой дизайна, а информацию - типа новости можно и из БД подкачать.

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

XML - это очередной способ заставить вас подарить деньги интелу. Сначала это был unicode (данные раздулись почти в 2 раза), теперь XML - "обертка" стала занимать больше, чем полезные данные. Все равно универсальности никакой нет - схему XML программа должна знать заранее. Как и структуру dbf-файла..

57, а что насчет API для работы с файлом обмена? Древовидные структуры данных, способа описания данных, способа преобразования таких данных? Возможность взаимодействия с такими данными в WEB?а причем тут интел?

+ вывод: нафик xml, даешь dbf, ага

При задачи обмена данными - я скорее всего так и сделаю.

Всем рекомендую покурить ЖКК по хмль :)Natanya Pitts. "XML In Record Time™", Sybex Inc., 1999(Натания Питс. "XML за рекордное время", М.: "Мир", 2000).99% вопросов и споров отпадет

56, по поводу быстродействия. У тебя, наверное, IBM PC/XT стоит? Помоему бред, считать быстродействие обработки текста объема переносимых данных на современных машинах с современными сетями передачи данных.

...и в 9 случаях из 10 ошибешься (я рассматриваю только случаи конфигурация 1С - конфигурация 1С)

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

Спасибо за рекомендацию, конечно почитаю. У меня не XT, а вот у пользователя, для которого я этот обмен делаю может быть по разному... например кассовый аппарат, свмещенный с компом., удаленная точка для просмотра, распечатки информации. я понимаю что вы верующий в XML, но ошибки мои конкретно в чём будут .... от формата обмена удобство пользователя не меняется никак, нибудет он лазить в файл и ручками там что-то править, или позовёт программиста. Его задача надавить кнопку "Выполнить", ну может ещё и файл указать. И чтоб программа этот обмен выполнила побыстрее. Всё! А из-за таких программистов как вы приходится менять компы у ВСЕХ пользователей чуть ли не каждый год. Иногда просто диву даешься как на пустом месте можно раздуть объёмы программ и снизить быстродействие.

в выборе, естественно :-)потому что реализация обмена займет у вас гарантированно больше времени, чем у специалиста, использующего КД - да, кстати, я не столько за хмл, сколько за КД, если вы еще не заметили...а вы сами сказали, что пользователь выбирает скорость :-)

"как на пустом месте можно раздуть объёмы программ и снизить быстродействие"Ага. Типичный пример такого подхода - 1c v8. Которая умудряется тормозить даже на 2*Xeon 3.2Ггц.

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

+68 К сожалению коммерческое приемущество - единственное приемущество, которое подеждает в нашем мире. Сейчас все живут жаждой наживы....

"Сейчас все живут жаждой наживы"Всегда большинство людей жило и будет жить жаждой наживы. Нормальный здоровый эгоизм. Живущие ради идеалистических целей просто не выживают. Закон жизни :)

Подведем итог: формат XML нужен для зарабатывания денег! :)

"Живущие ради идеалистических целей просто не выживают." не могу полностью согласиться с этим. Не было тогда бы свободно распостраняемых программ.Прочитал также книгу Г. Форда "Моя жизнь мои достижения" Не знаю как в самом деле, но по книге создается ощущение что прибыль была не главной его идеей. Хотя до этого слышыл, что конвейер и потогонная ситема - это его изобретения. Из книги получается что он сильно применял на практике эргономику. И нечего чел. выжил нормально и даже в истории отметку поставил.

разве не очевидно, что специалист, знающий и применяющий xml, dbf и txt будет успешнее, чем тот, кто знает только dbf и txt?

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

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

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

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

Вот именно! Все таки стандарт....

Чтобы узнать, чем все-таки хорош XML - читай www.script-coding.info. Раздел про XML.

- неправильно. Смотря какой метод формирования/парсинга и на каких объемах.В V8 XML является основным способом обмена.ДБФ и Текст оставлены для совместимости.

Пользователь в Это как раз IT специалист, котрый выбирает те технологии, которые позволят ему чувствовать себя уверенно на рынке IT. Конечно все мы знаем что самый оптимальный код писался на заре IT индустрии в двиочном коде, в лучшем случае на ассемблере и каждый байт там был на счету. А идти в ногу с прогрессом, и компы менять, и за "модой" следить тоже нужно, а иначе рискуеш остаться на обочине. Можно, конечно самому "моду" задавать - чем и занимаются всякие там Майкрософты и т.д. Вот создали XLM и давай его раскручивать, почти как в фабрике звезд. Вопрос только в том только эта звезда проживет, но могу сказать что живет она уже долго. Я работал с XML еще 1999 году. С тех пот эта технология все популярнее и популярнее.

(ALL) Кстати, полуофф: доку по Конвертации Данных где-нибудь можно взять? в электронном или бумажном варианте?у 1С есть такая книга в наличии, на продажу?

Пример (в терминах 1С). Попробуй прикинуть, каким будет формат txt-файла, если нужно передать объект "ТаблицаЗначений". Которая может, кроме скалярных данных, содержать вложенные таблицы и списки значений. То есть, уровень иерархии, состав и типизация полей заранее не определены.Думаю, в результате у тебя получится xml.

xml рулез, когда структура данных проектировалась в пьяном виде.. и про нормальные формы автор вообще не имел представления. Хотя сейчас реляционные БД - это не модно..

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

А при чем здесь мелго-мягкие? XML- стандарт W3C. Который активно поддерживают и продвигают не только MS, но и Sun, Oracle и другие зубры, которых в слепому следованию за MS не обвинишь.

У любой технологии есть сильные и слабые стороны. Фишка xml в том, что xml документ содержит не только данные, но и структуру этих данных. Структура данных описывается с помощью xsd схемы, например. Такая связка (данные + схема) позволяет проводить валидацию документа, создавать такие фичи, как типизированные дейтасеты. На основе xml создан протокол SOAP. А теперь, уважаемые непонимающие, попробуйте реализовать все это на txt и дбф - и ваше непонимание сразу пройдет :)

Не знаю, не знаю... Вот авторы третьего манифеста, например, так не считают...

http://zdnet.ru/?ID=499069 - вот интересная статья про web services. А web services - это в конечном итоге xml.

Стандарт на xml разрабатывает w3 консорциум: http://www.w3.org