зачем вообще нужен XML ?

Barbie29

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

Chupa

это всё секретный заговор фанатов лиспа против цывилизацыи

ppplva

хорошая видать трава была

Barbie29

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

Helga87

Например, для того, чтобы был возможен SOAP и Web Services. По крайней мере мне это жизнь сильно облегчает.

Barbie29

это как? ты типа создаешь свой протокол? послал число 222 показалась форма такаято? Я имел ввиду XML как контент-менеджмент чтоли...

Helga87

Нет, свой протокол я, конечно же, не создаю. SOAP - это протокол, основанный на xml, который позволяет вызывать методы web service-а. Благодаря тому, что он является открытым и для него не требуется специального парсера, делается возможным работа с web service-ами независимо от платформ клиента и сервера. В частности, можно с легкостью обращаться из .net-ного приложения к web service-у, написанному на Java. Кроме того, благодаря такой возможности сейчас активно развивается технология Rich Internet Applications (клиент - это флешка). Еще пример: google, yandex и другие поисковики предоставляют интерфейс на web service-ах. Недавно читал восторженную статью какого-то американского менеджера, который смог за час сделать Excel-евский документ, который проводил анализ популярности различных продуктов по интересующей его тематике, причем данные автоматически запрашивались через web service у Google. Наличие таких приложений явная заслуга xml.

FRider

Слушай, это...
Какието страшенные слова и выражения:
"толкования какого-то понятия" - это к филологам,
"структуризация понятий" - это к братве,
"тематическая рубрикация " - к библиотекарям чтоль

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

laki

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

sasha79

И не только!

laki

полностью согласен.
для России это не так актуально, но канадцкий сервис поиска адресов http://www.streetperfect.com
в Великобритании аналогичная вещь http://www.qas.com все основано на SOAPe, что значительно сокращает труд программиста и вводит определенные стандарты на использование

laki

поясни? чето туплю, че я не так написал.

sergei1969

Как то прочитал гдето в яндексе, какделать этот XML, насколько понял, там структуризация...

дальше можно не продолжать
почитай толком, что это такое, потом уже наезжай...

Hastya

Это конешно блаародно, но что мешает сделать бинарный протокол или использовать один из миллионов существующих вариантов RPC? зачем гонять все это через текст? в чем универсальность?

Dasar

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

Dasar

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

ppplva

В принципе, никто не мешает в критичных местах сворачивать xml в какое-то бинарное представление. А если так не делают - значит не надо. Или не стоит затраченных усилий.

Hastya

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

ppplva

Легкость отладки.
Плюс, в xml часто делают конфигурационные файлы.

Dasar

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

Dasar

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

Hastya

эта легкость кажущаяся
уже сейчас есть тонна отладчиков для SOAP
никто вручную с ним работать не будет
года через три начнется новый этап - Web Services пустят по другому протоколу, более экономичному, более приспособленному для транзакций.
и с точки зрения разработчика XML вообще умрет. потому что поверх него будут слои высокоуровневых протоколов.
вопрос: за что боролись? за 10 последних лет умерла туева куча таких протоколов. сейчас очередной виток изобретения велосипеда.

ava3443

> за 10 последних лет умерла туева куча таких протоколов.
приведи примеры?

bastii

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

bastii

Не умрет xml, это низкоуровневый формат, SOAP низкоуровневый протокол, все остальное строят над ними. Все дело не только в самом xml, а в том, что вокруг него получилось создать красивые api, который растут из простых и общих понятий, и дают большую гибкость для из реализаций. При этом какими бы извратными они не были, ты всегда смотреть на это как текстовое представление.

Helga87

Это конешно блаародно, но что мешает сделать бинарный протокол или использовать один из миллионов существующих вариантов RPC? зачем гонять все это через текст? в чем универсальность?

Вспомни с какой регулярностью находят дыры в RPC? Большая часть как раз связана, что для каждого сервиса придумывался свой бинарный протокол и его парсер, и, конечно, многие из таких протоколов недостаточно хорошо проверяют корректность приходящих данных. После того как появилась идея пустить RPC по SOAP, проблема некорректных входящих данных легла на слой, ответственный за работу с SOAP. В частности, они валидируются по wsdl описанию. Таким образом, вышележащие слои могут уже доверять корректности формы входящих данных. Т.е. чувак с telnet-ом на другой стороне уже ничего сделать не сможет. Поскольку для одной платформы достаточно только один раз написать парсер xml и уровень для работы с SOAP, они подвергаются более серьезному тестированию и содержат меньше ошибок. Когда с программиста снимается часть работы, я всегда говорю: "круто!".

Hastya

Не умрет xml, это низкоуровневый формат, SOAP низкоуровневый протокол, все остальное строят над ними.

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

Hastya

Вспомни с какой регулярностью находят дыры в RPC?

Это ты про buffer overflow? Уверяю тебя, с веб-сервисами будет гораздо хуже. Хотя бы потому, что они задуманы как "пропускаемые" через брэндмауэры.
XML как структурированный формат представления данных достаточно бесполезен - все равно саму модель мне приходится описывать с помощью схемы, а внутри схемы еще и проводить дополнительную валидацию в соответствии с моими бизнес-правилами. XML не облегчает мне работу ни на грош.
Использование XML и создание стандартов на веб-сервисы - решение компромиссное, и возникшее только благодаря пересмотру взглядов индустрии на открытые системы. Такой процесс сложно назвать эволюционным, скорее это очередная судорожная попытка индустрии к интеграции.

Helga87

Это ты про buffer overflow? Уверяю тебя, с веб-сервисами будет гораздо хуже. Хотя бы потому, что они задуманы как "пропускаемые" через брэндмауэры.

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

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

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



bool isLoggedIn = myService.Login(userName,  password);

Все это как-то прозрачно для тебя доставляется на сервер и вызывается метод



bool Login(string userName, string password)

{

...

}

Тебе осталось только проверить, что в качестве имени пользователя и пароля передали допустимую пару. Но тебе не надо думать что будет если на клиенте начнут вместо string пытаться послать int или вообще мусор всякий. Тебя от этого оберегают стандартными методами.
И ты еще хочешь сказать, что RPC, где обычно надо было вручную наводить сериализацию/десериализацию менее подвержен ошибкам?

Werdna

Этот весь XML заранее обречен

Говорить об обреченности xml, это то же самое, что говорить об обреченности стандарта POSIX, протокола http или формата gif. Был, есть и будет, ибо относительно прост, туп и несет все, что необходимо для отображения структур данных.

Werdna

некорректный с точки зрения протокола запрос просто не пропустят

А где ты видел, чтобы хоть кто-то что-то некорректное обрабатывал? Не, мы напишем только коррекстный exploit.
Насчет "сфорганил табличку excel из каких-то там ебических данных с гугла" есть боян:

- Итак, дамы и господа! Вы смотрите второй выпуск ток-шоу "КтоКого",
которое регулярно ведется в этой эхе и набирает неуклонную популярность среди
наших фидозрителей и ньюсослушателей. Давайте поприветствуем участников шоу!
По левую руку от меня web-дизайнер Васисуалий Пупкин, поклонник современных
визуальных технологий и удобства в работе! (камера плавно наезжает на
серьезного молодого человека с свежевыбритым лицом и ослепительной белозубой
улыбкой). Васисуалий, расскажите немного о себе.
- Web-дизайном я начал заниматься три с половиной месяца назад, так как
считаю, что в нашем мире трудно жить без своей домашней странички. Ее адрес -
http://www.liad.freeservers.com/~vasisualiy/pupkin.htm, и буквально позавчера
я добавил туда раздел, полностью посвященный моей любимой кошке Люське! Для
работы я купил себе Pentium III-650, лицензионную Windows NT (впрочем, я
планирую перейти на Windows'2000 - она намного красивее!) и Microsoft
FrontPage 2000!
- Это, конечно, потрясающе! Hо мне надо представить другого участника
шоу. Итак, по правую руку от меня - профессиональный сисадмин, фанат-юниксоид
Гига Битзе! (на сцену входит весьма небритый и суровый мужик с неизгладимыми
следами многолетнего пьянства на рабочем месте, под мышкой он держит ноутбук с
явственными вмятинами после недавней оргии). Гига, расскажите о себе,
пожалуйста, только коротко.
- HTML/DHTML, CGI/Perl, C/C++, Java, Javascript, Python, sh/sed/awk,
http://www.gigabitze.org (webmaster операционки: FreeBSD, Linux, BSDI,
OpenBSD, Solaris, SCO, компьютер: P133/16 (непринужденно помахивает
ноутбуком стаж 15 лет.
- Колоссально! А теперь перейдем непосредственно к вопросам. Васисуалий,
какими программными продуктами вы пользуетесь для создания своих
Web-страничек?
- Конечно же, Microsoft FrontPage 2000! Это же просто хит! Понимаете,
web-дизайнеру незачем отвлекаться на различные невероятно сложные и ненужные
процедуры вроде написания строчек текста. Это же творческая личность, у него
все должно быть под рукой! В инструкции к этой потрясающей программе так и
сказано: "Web-дизайнер может не знать HTML". И это действительно так! Вот
смотрите, давайте проведем эксперимент! Вот сейчас я сдвину логотип со своей
главной странички влево за две секунды! (легким движением мышки совершает
требуемое, бесцеремонно согнав ведущего с его компьютера). Вот, полюбуйтесь!
- Что ж, давайте посмотрим... Гига, прекратите блевать в пластиковый
пакет, вы же не в самолете! Приобщайтесь к современным технологиям! Разрешите
мне ваш ноутбук, пусть зрители убедятся, что Васисуалий прав... ой, а где у
вас мышь?
- Три года назад съела соседская кошка Люська. С тех пор не удосужился
купить...
- Ладно, тогда давайте сами. Зайдите пожалуйста на сайт Васисуалия, пусть
народ посмотрит (пальцы Гиги танцуют джигу на клавиатуре, которая по степени
раздолбанности смахивает на танцпол ведущих рейверских клубов). ОЙ, ЧТО ЭТО?!
- Это сайт моего любезного коллеги в Netscape (камера плавно наезжает на
Васисуалия, который, заглянув в ноутбук, отшатывается и рефлекторно пытается
перекрестится. Он издает жутчайший вопль, достойный администратора, у которого
полетел несбэкапленный файл с годовыми отчетами)
- В ЧЕМ?!
- Hу, в Netscape Navigator... знаете, браузер такой...
- То есть как это браузер? Вы мне мозги не пудрите, я же знаю, у браузера
в правом верхнем углу крутится буква "e", это мы еще в школе проходили. А это,
наверное, троян какой-нибудь.
- Да нет же, браузер! Я его сам компилировал! Вот, смотрите, вот он ваш
логотип... (мучительно прокручивая скроллбар) Во-оооон он, в самом левом углу.
- Hе может быть! Я ж его при вас смещал влево! Hе, неправильный у вас
браузер. Как вообще такой анахронизм мог сохраниться? Ему место в музее...
(согнутым средним пальцем показывая в ноутбук, из брезгливости опасаясь
приближаться к нему ближе чем на два с половиной метра).
- (Лицо Гиги Битзе начинает краснеть, на лбу проступает отчетливо видимая
в асральной плоскости (доступной лишь настоящим сисадминам) ненависть ко всему
мелкософтофскому отродью) #$%&* %^@" *%$! Это мой боевой трофей! Я его
честно выиграл в сеансе одновременной игры в Quake! И никому не отдам! #$%@,
нет, он на мой ноутбук покушается! Все видели?
- Да кому он нафиг нужен?!
- (Ведущий останавливает начавшееся было кровопролитие) Гига,
успокойтесь. Покажите лучше, как вы работаете над сайтом.
- Да запросто! Сейчас на нем и покажу... (Гига бросает злобный взгляд на
Васисуалия и запускает vim). Вот, смотрите, чего я напишу...
==>Смотрим на экран ноутбука
# vim /usr/temp/web/vpmd.html

Васисуалий, ТЫ HЕПРАВ!
~
:wq
file saved.
# sh sync http://liad.freeservers.com/vasisualiy/_vti_pvt/ -p pupkin
dirs synchronized.
==>Отрываемся от экрана.
Вот таким путем! Васисуалий, не смотрите, все равно ничего не поймете!
Лучше зайдите на свой сайт!
- А чего я там не видел?
- А вы зайдите, зайдите... Мир полон неожиданностей!..
- Hу ладно, сейчас.... (ведущий подключает свой многострадальный
компьютер к большому экрану, дабы зрители могли насладится свежим оригинальным
дизайном сайта Васисуалия, с многочисленными фреймами, скроллбарами и
картинками полиграфического качества и такого же размера). Hемая сцена, тишину
нарушает лишь легкий стук упавшей челюсти Васисуалия.
- ЭТО HЕ МОЙ САЙТ! И кстати, почему это я неправ?
- Как не ваш? Вы же сами говорили, что он доступен по этому адресу...
Господин Битзе, прекратите смеятся! Лучше помогите человеку проблему решить, у
него, похоже, браузер глючит...
- А по-моему, не глючит. Это я его сайт обновил. Сделал его, так сказать,
актуальным. Хоть щаз - на конкурс!
- Hо КАК? Васисуалий, вы что, дали ему пароль?
- H-ннет, не д-ддавал... а что такое "мастдай"?
- А зачем мне пароль? Мне пароль не нужен. Васисуалий, вы когда-нибудь
заглядывали в директорию /_vti_pvt на вашем сайте?
- У меня нет такой директории! Я ее не создавал!
- Проверьте сами. Попробуйте утянуть файл /_vti_pvt/administrators.pwd...
- Да откуда ему там быть? Хотя... ой, что это?
- Догадайтесь!
- Hет, неправда, это не мои пароли! Тут вообще мешанина какая-то...
- (Гига торжествующе демонстрирует ноутбук с окошком, в котором крутится
John The Ripper) А это что?
- (Васисуалий машет руками) Камеру! Камеру уберите! Как? Вы что, телепат?
- Hет, но ваш пароль - pupkin. Так ведь?
- Зачем при народе-то сообщать? Так откуда вы узнали?
- Пусть это останется моим профессиональным секретом. А вы пользуйтесь
своим фронтпэйджем, пользуйтесь... Чес-слово, доставили мне удовольствие...
- (Вмешивается ведущий) Итак, на

Barbie29

блин, структура данных gif - это яблоко, яблоко бывает красным, синим и зеленым. Но никогда не бывает жидким металлическим. А тут дают возможность конструировать понятия. Я не говорю што XML плох как протокол. Он вообще задумывался, насколько помню(детально не разбирался только как система структурирования текста. У разных людей разные понятия о одних и тех же вещах. Да, идея замечательная, если бы не... А полез везде, на клиент серверные части и т.п. конешно, удобно, не писать open(SOCK...)? , это да, но не более..

Werdna

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

vijrel7878

напомнило ракламу про какой-то растворимый суп и вкус мяса с кортавым челом в очках

FRider

А полез везде, на клиент серверные части и т.п. конешно, удобно, не писать open(SOCK...)? , это да, но не более..

Нет уважаемый.
Рассмотрим задачку авторизации клиента на сервере. Удобнее например писать:

Server.Authorize(login, password);

Чем вот так:



using (PasswordComparer pc = new PasswordComparer(password, ProtocolProvider.GetEncoding

{

     channel.Send(PacketBuilder.MakeAuthData (login, pc.HashPassword(sessionId.ToString;

} 

using (HeaderParser hparser = new HeaderParser(channel.Receive

{

     hparser.ParseHeader(Headers.OK);

}

Приведено из реального проекта системы клиент-сервер, где работать с сокетами пришлось ручками, а протокол придумывать свой. И разбирать вручную тоже. Метод MakeAuthData скрывает дохера кода создания пакета, нагенеренного кстати с помощью xslt.

Hastya

т.к. некорректный с точки зрения протокола запрос просто не пропустят

я говорю не про SOAP, а про XML как представление данных
"моделью" данных он не является, и в любом случае мне надо свою модель описывать, причем далеко не все бизнес-правила я могу задать в схеме.
Вопрос - нафига? Притом мне еще навязывается представление в виде иерархический элемент + текстовые атрибуты.

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

Любая RPC-библиотека позволяет мне об этом не заботиться.

И ты еще хочешь сказать, что RPC, где обычно надо было вручную наводить сериализацию/десериализацию

Нигде ничего не надо делать вручную. См. например RMI или IIOP. Все прекрасно работает.

Helga87

Отл.
К тому же RMI не подконнектишься так просто, кроме как из Java. Этим он хуже Web Services.

anton7805

Я не говорю што XML плох как протокол. Он вообще задумывался, насколько помню(детально не разбирался только как система структурирования текста. У разных людей разные понятия о одних и тех же вещах. Да, идея замечательная, если бы не... А полез везде, на клиент серверные части и т.п.

ну правильно, все стремится у унификации , и согласись в некотрых областях описанных выше xml и технологии на нем построенные несомненно рулят

VTISHKOV

А вот я считаю, что XML низачем не нужен, потому что как формат представления данных он связан с оверхедами - жрёт, сабака, канальную ёмкость при передаче и процессорную - при парзинге и формировании. Плюс, я не знаю ни одного нормального API для работы с ним.
Что же самое неприятное для меня лично в нём - так это сугубо мономорфный зарактер типизации, которую осуществляют DTD и XSD - а другие способы сегодня не используются. Скорее всего потому, что атцы-аснаватели XML не могут себе вообразить, что такое полиморфная типизация.

bastii

А че за типизация такая, и что не так с типами в xml?

Werdna

expat нормально парсит, и, главное, быстро.
я накидал плюсовый враппер на шаблонах, могу поделиться.

Dasar

> Любая RPC-библиотека позволяет мне об этом не заботиться.
еще раз спрошу, что делать с rpc, если модель сервера и клиента чуть-чуть отличается?
например, хотя бы вместо int-а используется float.
долго и нудно писать руками адаптер?

Julie16

>модель сервера и клиента чуть-чуть отличается?

У вас трава видать еще лучше чем у нас

Dasar

это стандартная ситуация - когда необходимо интегрировать БД или ПО нескольких производителей.
например, ФИО пользователей у всех будет,
но у кого это будет три поля (имя, отчество, фамилия
у кого-то одно (ФИО сплошной строкой
а у отдельных представителей два (имя и фамилия).
а дальше крутись как хочешь.

laki

VTISHKOV

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

Dasar

Пример, такой стыковки - это стыковка kinfo.ru с ozon.ru и bolero.ru.
Стыковка с ozon.ru у меня получилась в лет,
с bolero.ru возникла куча гемора (при чем у них даже plain-текст, а не бинарный формат)
у ozon-а каталог представлен в виде:

<yml_catalog date="2005-08-22 23:02">
<shop>
<name>Интернет-магазин оЗон</name>
<company>ООО "оЗон"</company>
<url>http://www.ozon.ru/</url>
<currencies>
<currency id="RUR" rate="1" />
</currencies>
<categories>
<category id="3">Дерево для Web</category>
<category id="5663" parentId="12264">Любовный роман</category>
<category id="5664" parentId="5663">Жюльета Бенцони. Кэтрин Коултер</category>
<category id="5665" parentId="5663">Сандра Браун. Сидни Шелдон</category>
<category id="5667" parentId="5663">Даниэла Стил. Патриция Мэтьюз</category>
<category id="5668" parentId="5663">Смолл Бертрис. Джуд Деверо</category>
<category id="5669" parentId="5663">Джулия Гарвуд. Розмари Роджерс</category>
...
<offer id="1488071" type="artist.title">
<url>http://www.ozon.ru/?from=partner&context=detail&id=1488071</url>
<price>903</price>
<currencyId>RUR</currencyId>
<categoryId>6833</categoryId>
<picture>http://mmedia.ozon.ru/multimedia/video_covers/small/1000073943.gif</picture>
<orderingTime>
<ordering>На складе</ordering>
</orderingTime>
<title>Коллекция Ингмара Бергмана №1 (7 кассет). Как в зеркале (Сквозь мутное стекло)</title>
<year>2003</year>
<media>VHS</media>
<starring>Харриет
Андерсон, Макс
Фон Сюдов, Гуннар
Бьернстранд, Ларс
Пассгорд</starring>
<director>Ингмар
Бергман</director>
<originalName>Sasom i en spegel / Through a Glass Darkly</originalName>
<country>Швеция</country>
</offer>
...

Bolero.ru

_ID категория название производитель|автор|режисер|исполнитель год выпуска цена ссылка (страницу описания)
22119016 Видео>Драма>Романтика Кармен 2003 212.00 http://www.bolero.ru/index.php?level=4&pid=22119016
22119017 Видео>Боевики и приключения>Приключения Однажды в Токио 2003 188.00 http://www.bolero.ru/index.php?level=4&pid=22119017
22119018 Видео>Аниме Однажды в Токио 2003 188.00 http://www.bolero.ru/index.php?level=4&pid=22119018
22119020 Видео>Драма>Криминальные драмы Адский поезд 1984 161.00 http://www.bolero.ru/index.php?level=4&pid=22119020
22119021 Видео>Боевики и приключения>Триллеры Тысяча миллиардов долларов 1982 161.00 http://www.bolero.ru/index.php?level=4&pid=22119021
22119022 Видео>Боевики и приключения>Детективы Тысяча миллиардов долларов 1982 161.00 http://www.bolero.ru/index.php?level=4&pid=22119022
22119023 Видео>Драма>Криминальные драмы Тысяча миллиардов долларов 1982 161.00 http://www.bolero.ru/index.php?level=4&pid=22119023
22119024 Видео>Триллер>Детективы Тысяча миллиардов долларов 1982 161.00 http://www.bolero.ru/index.php?level=4&pid=22119024

для bolero.ru, кроме написания своего csv-парсера, так же приходится постоянно отслеживать изменения формата.
по bolero.ru видно, что они сильно ограничены табличной структурой, поэтому им приходится в одно поле, запихивать кучу разнородной инфы.

FRider

ты сам понял чо сказал?
Xpath - это язык запросов к хмл документу. При чем тут апи?

VTISHKOV

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

Helga87

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

1. Не стоит оскорблять собеседника. Есть мнение, что это не лучшим образом говорит об оскорбляющем. Собеседник лучше воспримет твое мнение, если ты его грамотно аргументируешь.
2. XPath не является языком преобразований. Он не позволяет модифицировать xml документ. Это язык запросов, т.е. единственное его назначение в том, чтобы выбирать вершины, подходящие условиям.
3. По моим наблюдениям XPath является одним из тех языков, семантика которых становится очевидной после того, как увидишь пару-тройку примеров запросов.
Возможно, ты путаешь XPath и XSLT? XSLT действительно призван преобразовывать исходное дерево в выходное, и кроме того, он не слишком понятен.

VTISHKOV

1. Не стоит оскорблять собеседника. Есть мнение, что это не лучшим образом говорит об оскорбляющем. Собеседник лучше воспримет твое мнение, если ты его грамотно аргументируешь.

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

Возможно, ты путаешь XPath и XSLT? XSLT действительно призван преобразовывать исходное дерево в выходное, и кроме того, он не слишком понятен.

Да, я имел в виду XSLT

laki

>>>>> Да, я имел в виду XSLT
тебе сюда

FRider

Вот пожалуйста, уважаемый, выражайтесь четко и ясно, чтобы не было недопониманий.
Режим WiteOnly не очень хорошо влияет на собеседников.
А то увас получается "Мы говорим партия, подразумевем Ленин..."
Опять же, ваша реплика про "событийно-ориентированный" апи совершенно не ясна. Уточните конкретно, что за апи, из какой библиотеки. Иначе вы абсолютно не правы, например в .Net framework нет никакой ОРИЕНТАЦИИ на в xml api. Рожайте себе хмл документы на здоровье без XPaht и событий.

VTISHKOV

Опять же, ваша реплика про "событийно-ориентированный" апи совершенно не ясна. Уточните конкретно, что за апи, из какой библиотеки.

Имелся в виду expat, читаем внимательно, ответом на какие постинги является критикуемый.

Иначе вы абсолютно не правы, например в .Net framework нет никакой ОРИЕНТАЦИИ на в xml api. Рожайте себе хмл документы на здоровье без XPaht и событий.

Не знаю, как это делается в .net fw, но уверен, что API там тоже уродский - ничуть в этом смысле не отличающийся от, например, DOM.

laki

Не знаю, как это делается в .net fw, но уверен, что API там тоже уродский - ничуть в этом смысле не отличающийся от, например, DOM.

Какой не уродцкий по твоему мнению?

ava3443

У него SAX уродский, DOM уродский... может всё проще - плохому танцору что-то мешает?

FRider

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

Не знаю, как это делается в .net fw, но уверен, что API там тоже уродский - ничуть в этом смысле не отличающийся от, например, DOM

Там есть DOM, там есть реализация SAX. Вот не надо писать, "я не знаю, но уверен." Посмотрите, попользуйтесь...

VTISHKOV

Какой не уродцкий по твоему мнению?

Плюс, я не знаю ни одного нормального API для работы с ним.

Лучше всего было бы, если бы структуры данных языка отображались каким-то простым и прозрачным образом в обе стороны когда есть типизация через XSD и т.п. (jaxb не предлагать...) и в какие-то тоже удобные и простые сущности (м.б. какой-то синтаксический сахар когда типизации нет. Хочется также на уровне каких-то конструкций языка типа циклов иметь возможность просматривать документ последовательно без его полной загрузки в память (и точно так же писать) - чтобы сборщик мусора подъедал то, что уже просмотрено и забыто, и транслятор бы нарожал ему хинтов (но если я чего не забыл, то чтобы оно оставалось в виде нормальных структур данных). Как-то так

VTISHKOV

Блин, что значит "не надо писать"? Я пока не планирую ничего писать на .net, и меня интересует то, можно ли нормально работать с XML в первую очередь в Java - и отчасти традиционном C++ на юнихах. И в этих мирах всё с XML крайне плохо. И это первый пункт моей критики - если миллионы человеко-часов не породили ничего нормального, то вообще есть ли шанс? - уродский API
Второй пункт - XML убог сам по себе и не позволяет ряд вещей, которые хочется иметь - а хочется иметь возможность описывать XML-схемы для хранения каких-то абстрактных данных, тип которых не известен на момент написания схемы и будет меняться. - тупая концепция
Третий пункт - реляционные данные на XML ложатся плохо, а ими обмениваться тоже надо. - неполная универсальность
Четвёртый пункт - он неэффективен по трафику и жору CPU. - оверхеды
Ещё?
Вывод - технология пока несовершенна, проклят всяк кто заложится по-крупному

Helga87

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

XmlSerialization + XmlValidationReader в .NET Framework.
Пример:
Есть xml-файл следующего вида:



<?xml version="1.0" encoding="utf-8" ?>

<Cars>

	<Car>

		<Manufacturer>Mercedes</Manufacturer>

		<Model>600</Model>

		<Age>7</Age>

	</Car>

	<Car>

		<Manufacturer>Победа</Manufacturer>

		<Model>Э-1</Model>

		<Age>47</Age>

	</Car>

</Cars>

Мы его хотим загрузить в структуры языка вида:



    [XmlRoot(ElementName="Cars")]

    public struct CarCollection

    {

        [XmlElement(ElementName="Car")]

        public Car[] Cars;

    }

    public struct Car

    {

        public string Manufacturer;        

        public string Model;

        public double Age;

    }

И можем как загрузить:



CarCollection Load(Stream stream)

{

      XmlSerializer s = new XmlSerializer(typeof(CarCollection;

      return (CarCollection) s.Deserialize(stream);

}

Так и сохранить:



void Save(Stream stream, CarCollection cars)

{

      XmlSerializer s = new XmlSerializer(typeof(CarCollection;

      s.Serialize(stream, cars);

}

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

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

ava3443

Я так понял, насчёт SAX & DOM по существу ответить нечего?

ava3443

> реляционные данные на XML ложатся плохо
что именно плохо?

bastii

В .NET xml api лучше чем DOM и SAХ -- там xml reader, хотя DOM тоже есть.

Julie16

Ух ты, а если я в него(в NET) загружу файл мег эдак в 600, сколько он там займет(в смысле сколько отожрет оперативки)?

bastii

DOM плохо из-за нагрузки на память, SAX имхо просто неудобно

bastii

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

Julie16

А если мне нужно сделать внешний loop(цикл обработки потока данных не у них а у меня)?

bastii

так ты сам и вытягиваешь хмл из ридера своим циклом, а не как в сакс, где цикл внутренный

bastii

using System;

using System.IO;

using System.Xml;

public class Sample {

  private const String filename = "items.xml";

  public static void Main {

  

     XmlTextReader reader = null;

     try {

       

        // Load the reader with the data file and ignore all white space nodes.         

        reader = new XmlTextReader(filename);

        reader.WhitespaceHandling = WhitespaceHandling.None;

        // Parse the file and display each of the nodes.

        while (reader.Read {

           switch (reader.NodeType) {

             case XmlNodeType.Element:

               Console.Write("<{0}>", reader.Name);

               break;

             case XmlNodeType.Text:

               Console.Write(reader.Value);

               break;

             case XmlNodeType.CDATA:

               Console.Write("<![CDATA[{0}]]>", reader.Value);

               break;

             case XmlNodeType.ProcessingInstruction:

               Console.Write("<?{0} {1}?>", reader.Name, reader.Value);

               break;

             case XmlNodeType.Comment:

               Console.Write("<>", reader.Value);

               break;

             case XmlNodeType.XmlDeclaration:

               Console.Write("<?xml version='1.0'?>");

               break;

             case XmlNodeType.Document:

               break;

             case XmlNodeType.DocumentType:

               Console.Write("<!DOCTYPE {0} [{1}]", reader.Name, reader.Value);

               break;

             case XmlNodeType.EntityReference:

               Console.Write(reader.Name);

               break;

             case XmlNodeType.EndElement:

               Console.Write("</{0}>", reader.Name);

               break;

           }       

        }           

     }

     finally {

        if (reader!=null)

          reader.Close;

     }

  }

} // End class

Marinavo_0507

Это типа преобразование, удаляющее пробелы?
Наглядный пример, демонстрирующий кривость API.

bastii

Не понял, в чем кривость апи?

Marinavo_0507

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

bastii

Блин, это пример из MSDN на XmlReader, который показывает идею того, как им пользоваться, он не решает никакую задачу.

Marinavo_0507

Плохой пример.
Никакой задачи не решает, а 10 кейсов.
Хорошие есть?

bastii

Зато сразу понятно, как xml парсить. Это же самый низкий уровень апи. Точно так же текстовый ридер (c методом ReadLine не решает проблемы с удаление определенных символов. Как обычно, это делается композицией ридера с фильтрующим ридером.

Dasar

> Кривость в том, что нужно явно рассмотреть 10 случаев, не имеющих отношения к задаче.
Это самый нижний уровень.
нижний уровень - должен быть быстрым, чем удобным.
> В более полезном случае (удалить не пробелы, а какие-нибудь элементы, скажем) таких случаев было бы 9, если писать в этом же стиле.
Сделай надстройку, для которой тебе нужно будет указывать только один case.
ps
кстати такой надстройкой, например, является xslt.
можешь его заюзать, если тебе не нравится низкоуровневое api.

Marinavo_0507

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

ava3443

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

bastii

ИМХО нужно смотреть на XmlReader, как абстракцию потока xml инфосета, которая лежит в основе нижнего уровня xml api в .net. Он играет аналогичную роль, что другие ридеры в таких апи как, например, ввод/ввывод (BinaryReader, TextReader). Использование таких абстракций делает апи очень гибким. Для определенных задач всегда можно сделать специфическую реализацию, которая в данном случае больше подходит, и при этом иметь возможность использовать имеющуюся функциональность (алгоритмы, апи более высокого уровня заданную в общих терминах ридера. Понятно, что для xml существуют необходимые апи высокого уровня -- например, сериализации ().

Marinavo_0507

> а исходная задача вроде и не подразумевала наличия парсера,
> ведь речь шла о преобразовании?
Если пример демонстрирует парсер, то преобразование должно
включать себя декодирование, обработку, и кодирование результата.

Marinavo_0507

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

bastii

Ну я не отец xml api в .NET, но вроде с атрибутами так же как и с элементами: ты прыгаешь по узлам (элементы, атрибуты и т.д.) вызывая Read и всякие MoveToXXX тип узла, на котором сейчас находишься в текущий момент определяешь с помощью свойства NodeType. С помощью других методов и свойств получаешь необходимые значения и имена узлом. Точнее не скажу, сейчас нет ни VS, ни MSDN.

Marinavo_0507

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

это на DOM сильно похоже
а я про сериализацию говорил

Helga87

XML:

<?xml version="1.0" encoding="utf-8" ?>

<Cars>

	<Car lotId="1">

		<Manufacturer>Mercedes</Manufacturer>

		<Model>600</Model>

		<Age>7</Age>

	</Car>

	<Car lotId="2">

		<Manufacturer>Победа</Manufacturer>

		<Model>Э-1</Model>

		<Age>47</Age>

	</Car>

	<Moped lotId="333">

		<Name>Матароллер</Name>

	</Moped>

	

</Cars>

Описание структур:

    [XmlRoot(ElementName="Cars")]

    public struct CarCollection

    {

        [XmlElement(ElementName="Car", Type=typeof(Car]

        [XmlElement(ElementName="Moped", Type=typeof(Moped]

        public object[] Cars;

    }

    public struct Car

    {

        [XmlAttribute(AttributeName="lotId")]

        public int LotId;

        public string Manufacturer;

        

        public string Model;

        public double Age;

    }

    public struct Moped

    {

        [XmlAttribute(AttributeName = "lotId")]

        public int LotId;

        public string Name;

    }

bastii

DOM немного не то, в XmlReader ты прыгаешь только в одном направлении. Кроме XmlTextReader есть XmlNodeReader, который прыгает по DOM дереву. К сериализации это все прямого отношения не имеет.

Marinavo_0507

Во, гораздо лучше. Хотя конечно без вариантов плохо - object[] получается.
А рекурсивные типы бывают?

Helga87

Рекурсивные, это типа так?

  

public struct Directory

{

  [XmlElement(ElementName="Directory")]

  public Directory [] SubDirectories;

  [XmlElement(ElementName="File")]

  public File [] Files;

  public string Name;

}

...

Да, можно.

bastii

Жалко, что ссылок нет, т.е. циклы в графе объектов уже не поддерживаются.

Marinavo_0507

В XML и не бывает циклов, так что нормально.

bleyman

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

bastii

В XML может и нет, но в структурах объектов часто. Например так:



class A {

    public string name;

    public B[] bs;

}

class B {

    public A inA;

    public string name;

}

Хотелось бы, чтобы можно было настраивать движок сериализации, чтобы inA тоже заполнялись, хотя в XML их хранить возможно и не имеет смысла.

bleyman

Dasar

Понятно, что, например, SoapSerializer сохранит в xml произвольный object-ный граф.
но это не совсем то, что хочется.

bastii

XML как раз хочется, чтобы был такой же, как без inA.

bleyman

> XML как раз хочется, чтобы был такой же, как без inA.
Сам-то понял что сказал?
2ДаркГрей: А чего хочется?

Dasar

например, то, что сказал -
например, чтобы вот такой xml:



<Car>

  <Wheel radius='3'/>

  <Wheel radius='3'/>

  <Wheel radius='3'/>

  <Wheel radius='4'/>

</Car>

грузилось вот в такую структуру данных:



class Car

{

  public Wheel[] Wheels = new Wheel[]{};

}

class Wheel

{

  public double Radius;

  public Car Car;

}

причем ссылка на Car устанавливалась - "сама".

bleyman

> причем ссылка на Car устанавливалась - "сама".
Ссылка не телепат, она читать твои мысли не умеет. Ты хочешь устанавливать неинициализированные ссылки в непосредственного парента, Вася Пупкин - в нулл, Глеп Петрович - в следующий элемент, а Гильям Вейтс предпочитает пройтись наверх по всей иерархии в поисках наиболее близкого типа. Если скрестить все эти поведения, то система станет пиздец неустойчивой и непонятной.
Ты можешь явно декларировать в каждом Wheel ссылку на Car так, как это делает дефолтный сериалайзер (я не видел, но он это делает всё равно хмлку не ручками пишут обычно.
Ты можешь написать свой десериалайзер, который будет восстанавливать непереданную информацию так, как ты хочешь, а потом с ним ебаться. Насколько я помню, в .нет можно было просто повеситься на специальный эвент у стандартного десериалайзера.
Но лучше всего конечно же пометить Wheel.Car как [NonSerializable], отнаследовать все свои классы от специального класса в котором есть виртуальный AfterSerialization, оверрайднуть его у Car и проставить все ссылки. К сожалению, насколько я опять же помню, аналогичный метод ISerializable нельзя использовать параллельно с автоматической сериализацией. Вот.
ЗЫ: А. Это я невнимательно читаю, наверное. Последний обзац можно запостить четыре поста наверх, потому что вы об этом говорили, наверное, а я тупил.

Dasar

> Ссылка не телепат, она читать твои мысли не умеет
дык, про то и речь, что не хватает аттрибутов Parent, Brother и т.д.

bleyman

Добавь.
Пара дней размеренного секса, и у тебя будет сериализатор/десериализатор, который понимает такие и многие другие атрибуты. Ты даже наверное их несколько раз поиспользуешь.

bastii

Это будет только начало. Там еще много чего можно захотеть от сериализации. Если уж делать нормальный движок, то делать это нужно основательно. Например, хотелось бы уметь сериализовывать произвольные классы, а не специально помеченные атрибутами (плюс гибко настраивать, используя какие-нибудь файлы отображения). Эффективную реализацию динамического построения сериализатора (благо в версии 2.0 появилась легкая генерация кода и более качественная реализация рефлексии плюс внятная модель статической генерации сериализатора (хотя что подобное появилось в 2.0). Пока XML не покоряется Майкрософт: сырой апи (а хочется стройный и вылизанный бедная функциональность, куча движков сериализации (старый, XAML, что-то в Indigo скорее всего свое но ни один не тянет на универсальный. Хотя вроде проблема с XML должна основательно и в комплексе решаться в 3.0 (так по крайней мере обещают) -- посмотрим.

Оставить комментарий