Все новости от 16 января 2003 г.

XML — вопрос аппаратуры?

Речь идет об XML, или eXtensible Markup Language. Прежде чем коллега из соседнего кабинета испортит вам ланч скучным и длинным монологом на эту тему, дадим краткое определение XML. Это формат, включающий, кроме самого текста, информацию о том, в каком виде этот текст существует: шрифты, размеры, форматы, расположение — все, что влияет на общую структуру документа.

Конечно, прежде всего вам потребуется больше памяти. Кроме желаемых данных, теперь придется хранить всю информацию о том, как они выглядят и что из себя представляют. Как скажется на вашем бюджете, положим, 10-кратное увеличение емкости дисковой памяти? Но это еще не все. Если код ASCII можно сравнить с ведром с краской, которая ждет, чтобы ее выплеснули, то XML — это, скорее, Матисс, представление слов и образов в нетрадиционной манере, поиск нового художественного пространства в рамках структуры документа. Иными словами, для его перевода с диска на экран требуется значительная обрабатывающая мощность. Если преобразование обычного текста происходит в пределах процессора и памяти сервера или рабочей станции, то программное обеспечение для работы с XML потребует для кодирования и декодирования более мощного оборудования.

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

Сейчас XML тащится по сети на тяге программных интерпретаторов и акселераторов — это напоминает ситуацию, когда GUI вытягивали те первые графические платы. Новое решение, как и в случае графических плат, должно перевести интерпретацию и акселерацию на аппаратные рельсы — и, как и с теми первыми графическими платами, это будет не та аппаратура, которая существует сегодня. (Это несколько чрезмерное упрощение, но в целом все верно.)

Догадайтесь, какая? Если за простые графические платы покупатели десктопов платили по 100 $, то более мощные, с графическими процессорами, обходятся в четыре-пять раз дороже. То же справедливо и для XML-серверов — так что разумная цена каждого из них может перевалить за 55 тыс. $. В зависимости от размера серверной фермы это может пробить заметную брешь в вашем бюджете — и ради чего? Ради красивого текста! От этого никуда не деться. Со временем придется добавить XML-сервер или по крайней мере какую-нибудь плату XML-интерпретатора в рабочие станции. Но не стоит обманывать себя тем, что это расходы, связанные с технологическим прогрессом. XML — всего лишь еще один пример подхода: «Эй, посмотрите, что мы сделали просто потому, что можем!». 

 Предыдущие публикации:

Обсуждение и комментарии

	DemonZla 16 Jan 2003 4:26 PM
Издращенцы... всё им денег мало... опять формат угробят...
	Пётр - peterkdhotmail.com 16 Jan 2003 5:20 PM
это точно. Уже тут была, статья про XML на кристалле. Опять начнутся спора о том какой парсер лучше - программный или аппаратный.
	Shadow 16 Jan 2003 5:30 PM
IMHO, программный на RISC платформе.
	Пётр - peterkdhotmail.com 16 Jan 2003 6:19 PM
что же это за монстр такой будет?
	DenisHorror 16 Jan 2003 7:11 PM
Что-то фраза "Это формат, включающий, кроме самого текста, информацию о том, в каком виде этот текст существует: шрифты, размеры, форматы, расположение — все, что влияет на общую структуру документа." отдает конкретным дилетантизмом. XML - это язык логического форматирования данных + плюс море технологий их обработки, а это отнюдь не шрифты и текст. Это лишь частный случай. Поэтому и проблема упирается в конкретные задачи. В случае хранения данных я не совсем понимаю, чем по нагрузке на сервер XML отличается от прочих технологий. Речь скорее всего идет о том, что технология столь популярна и позволяет просто решать масштабные задачи, что пора создать аппаратные ускорители. А пугать ценами, пожалуйста, не надо... Сервер покупают под задачу, а под парсер.
	00alex - 00alexmail.ru 17 Jan 2003 2:55 AM
Откуда этот Билл О'Брайн взялся? Прочитал бы пару книжек об XML, можно подумать <HTML> или .DOC (Word) - это такой простенький ASCII, который ни капли информации о разметке не содержит. А как она простите форматируется? Методы обработки XML тоже совершенствуются. Да можно сказать, есть операции в которых использование XML как хранилища понижает производительность. С другой стороны, оно в разы снижает время разработки _НАДЕЖНЫХ_ программ оперерующих разнородными данными. А что сейчас ценится больше? Время программиста и простой от нерешенной задачи, или сервер?
	tstone - saldomail.ru 17 Jan 2003 8:30 AM
> А что сейчас ценится больше? Время программиста и простой от > нерешенной задачи, или сервер? Отвечать обязательно? :)))
	Noname 17 Jan 2003 9:59 AM
Это попытка создать универсальный формат обмена данными. Думается, не последний. Всякий универсализм несет противоречия в самом себе. Попробуйте скрестить Мерседес и бульдозер. ХМL - это программный аналог офисных комбайнов. Недостатки их общеизвестны.
	glassy 17 Jan 2003 11:27 AM
2tstone: да, о таких вещах забывать нельзя :)
	torvic 17 Jan 2003 4:08 PM
2- DenisHorror /* Поэтому и проблема упирается в конкретные задачи. В случае хранения данных я не совсем понимаю, чем по нагрузке на сервер XML отличается от прочих технологий */ Раз уж уперлись в конкретную задачу хранения данных, то что непонятно чем отличается по нагрузке на сервер от РБД ???
	kvasim 17 Jan 2003 8:58 PM
люди обясните мне тупому дамеры в эти соврменных инфор технологиях: зачем придуман XML? зачем он такой тяжелы что под него ааапаратуру надо менять? я так думаю если он не будет идти на ipaq наример то фиг он кому нужен .. а вообщето не на ipaq( все таки 200 mhz .. а на Palm).. и вообще ничего не понимаю придумывают какие то стандраты тяжелы что бы потом чтое под них подтрсивать вообщето всегда было наоборот делали старндарт исходяти из необходимости и возможностей..
	DenisHorror 17 Jan 2003 9:52 PM
2 kvasim В самом XML нет НИЧЕГО сложного. Позволю себе сказать, что проще пока не придумали (http://www.citforum.ru/internet/xmlspec/index.shtml). Вокруг рождается масса технологий, завязанных на нем. (уже не удивляет, что что-бы динамически генерить HTML нужен, например, PHP или JSP и, к примеру, SQL база данных). Вот собственно и объяснение - чем дальше, тем круче. Ну да... А ссылку на XML/XSL парсер для Palm где-то видал... Урезанный наверное :)
	Mossy 18 Jan 2003 1:23 AM
Бред какой-то... Тяжко ему видать... XML тормозит потому что много лишних данных гонять приходится с диска и проч... Акселератор XML - это более быстрые диски и память... Уж со стеком, который основа распознователей то и нынешние процы вполне себе аппаратно справляются.
	glassy 18 Jan 2003 7:31 AM
2DenisHorror: ответь на простой вопрос -- почему для передачи данных разного характера должен использоваться XML?
	quadic 18 Jan 2003 5:23 PM
2glassy: "почему для передачи данных разного характера должен использоваться XML" это, имхо, для тех людей, которым надоело писать парсеры/валидаторы/конвертилки и прочую фигню на каждый отдельный случай.
	ish-west 18 Jan 2003 7:59 PM
5 претензий к XML: 1) XML не умеет массивы (т.е. конечно это можно обойти, но удобства и скорости это не добавляет); 2) В XML нет типизации данных (это нужно бывает не часто, зато уж если понадобилось...); 3) (2.5 по сути) в XML не предусмотрена проверка на граничные значения и т.п.; 4) Не предусмотрена возможность бинарных нодов (обойти это можно, но вот всякого полезного API нет, типа извольте сами выкручиваться); 5) XML считается текстовым форматом, хотя с точки зрения транспорта ведет себя как бинарный (сколько раз необученный русский Апач перекодировал юникодный XML из koi в win... + эффективность с точки звения bandwidth-а, секурнсть, да и парсить правильно придуманый бинарник быстрее). Ну вот типа того... крик души и все такое :-)
	quadic 18 Jan 2003 8:42 PM
2ish-west 2-3) вот пример из MSXML 4.0 SDK, XSD reference: <xs:element name="quantity"> <xs:simpleType> <xs:restriction base="xs:positiveInteger"> <xs:maxExclusive value="100"/> </xs:restriction> </xs:simpleType> </xs:element>
	DenisHorror 18 Jan 2003 10:45 PM
2 ish-west & glassy Что-то вы не о том... Суть XML проста: просто логически структурированные данные в виде произвольных тегов и собственно данных. Что записал туда - то и будет. (1) Если угодно, то можно сформировать в структуру массива... (2) К данным приложил валидатор в виде DTD или Scheme, (3) где описал ограничения к содержимому тегов т.е. данным. (4) Данные могут быть любые (про voice XML не слышали?). (5) Дальше все проходит через XML парсер, который проверяет синтаксис, структуру и ограничения. А вот далее берем XSL и трансформируем данные на XSL парсере во все, что угодно. Зачем надо: Да надо просто договориться об общем формате, чтоб не писать каждый раз "парсеры/валидаторы/конвертилки", а использовать XSLТ style sheet, написать который под силу любому студенту. Чтобы сделать свое приложение раз и навсегда совместимым с другими - идеальный способ создать XML прослойку, а еще идеальнее изначально хранить все данные в XML. Таким образом мы имеем данные, отделенные от логики форматов (или оформления). XML - это не язык программирования (хотя для работы с ним созданы адаптированные языки, например XSP), а универсальный носитель данных.
	glassy 19 Jan 2003 7:57 AM
2DenisHorror: "Чтобы сделать свое приложение раз и навсегда совместимым с другими - идеальный способ создать XML прослойку, а еще идеальнее изначально хранить все данные в XML" Для этого необходимо описать семантику твоих тегов, причем в двух местах -- в твоем приложении, и в общедоступном месте -- это для всех других. Вопрос об использовании/не использовании XML как языка обмена данными имел место в E-Develop прошлой весной. Подавляющим большинством XML был отвергнут, наверное, потому что там не ламеры/ит-менеджеры, да и сама идея использования XML была студентом предложена. Надеюсь, ты не будешь спорить, что удобнее пользоваться функциями вида put_data(file_descriptor, data, data_descriptor, compression_level); data = get_data(file_descriptor, data_descriptor); и data = get_data_converted(file_descriptor, data_descriptor_in, conversion_descriptor); По сравнению с таким апи XML -- от Лукавого.
	quadic 19 Jan 2003 4:43 PM
2glassy: 1) "put_data(file_..." ты только не объяснил, откуда берутся эти функции (писать их всякий раз заново?), что делать, если тут данные формирует, скажем cgi, писаный на С, а там (далекоо) их должна обрабатывать хранимая процедура в oracle (писать два экземпляра - на С и PLSQL или жабе? А еще есть и юзаются VBA, Delphi, JScript, perl, python, TransactSQL, C#...) 2) данные передаются по гнусным каналам и бьются или их формируют тетки за 2 года до пенсии, а сами данные имеют весьма сложную иерархическую структуру и "ветки" могут отсутствовать или иметь подветки (например - полная информация о клиенте, список банков, через которые он работает + список счетов в каждом из банков, список услуг, получающих от нашей конторы и т.д.) - короче, валидатор нужен, причем даже того, что уже есть (XSD/DTD) часто маловато. 3) неплохо эту информацию, выдаваемую CGI/ASP получать еще, например, и в HTML для интрасайта - или ты пишешь сам конвертилку своего формата в HTML, или пишешь еще один CGI, выдающий инфу в HTMLе. P.S. Таких форматов дофигища, все это надо было "вчера", а в твоем распоряжении - 80% теток за 2 года до пенсии.
	glassy 20 Jan 2003 8:43 AM
2quadic: то есть ты хочешь сказать, что в случае с xml тебе не надо лезть в оракл/vba/delphi/JScript и проч.? Или мы к работе с аттрибутами/детьми уже привыкшие? Если есть люди, которых xml хоть в чем-то не устраивает, то карандаш в зубы и марш писать ТЗ.
	dem 20 Jan 2003 11:49 AM
2glassy Ты прям экстремист какой-то. XML уменьшает программирование за счет XSLT и прочих XML-FO. Это действительно удобно. И массивы и ограничения и бинарные данные предусмотрены. Есть даже подобие ссылочной целостности в БД. Я лично пока столкнулся только с одной проблемой. Если кто знает как делать БОЛЬШИЕ XML? (100мб например). дело в том что DOM это все делает так: Сначала создаем ветвь, а потом добавляем ее в узел. А это все в памяти. Парсить, нет проблем, а вот создавать.... Кстати я думаю врядли массовые акселераторы будут железкой (помоему их уже COMPAQ делает), скорее это будет очередной MMX-SSE только на Х. Ж:-)
	glassy 20 Jan 2003 1:34 PM
2dem: 2 вещи -- 1. зависимость к libxml 2. широкое использование str* функций
	dem 20 Jan 2003 2:17 PM
2glassy тут ты прав, но: 1)я не знаю как там в С++, но в Python нет привязки к xmllib и так-же я думаю в других языках (для явы там вообще всяких експатов с херцесами - куча). 1.1.) Статически линкуй 1.2.) Уже есть привязка к glibc, и ничего - живем. Бо OpenSource рулит. 2.) У всего есть свои плюсы и минусы (Всеравно это все сериализуется из объектов и восстанавливается туда-же)
	glassy 20 Jan 2003 3:24 PM
2dem: наладонику такое обращение нафиг не надо. Но раз уж код сделан, но на писюках он будет рвать, в чем его преимущество.
	dem 20 Jan 2003 4:52 PM
2glassy Слушай ну что ты пристал к этим наладонникам? IMHO их ниша - терминалы, а там данных 0.1% сплошной реалтайм. Я вот делал кучу костылей для торговой АРМ. там и ценники, там и репликации и прочие отчеты с извращенностями. А что самое главное я не знал что завтра попросят. Так вот раза так с 5 - пошел купил книжки, почитал и стал пробовать XML. Да это не панацея, но с тех пор я вместо тучи конверторов, отчетов и прочей лабуды, использую 1 конвертор + обвязка для получения КОНКРЕТНОго документа или файла. там цепочка какая? ИЗВЛЕЧЕНИЕ ДАННЫХ-ФОРМАТИРОВАНИЕ/ОТБОР-ПРЕОБРАЗОВАНИЕ В КОНЕЧНЫЙ ФОРМАТ. Так вот 1 и 2 части теперь в 1 куске, а не в 1000 и базу если переделал, переделываеш 1 кусок, а не 1000 почти похожих.
	DenisHorror - denishorrorhotmail.com 21 Jan 2003 9:03 AM
2 Dem А не кинешь письмецо? Есть пара вопросов ;)
	glassy 21 Jan 2003 9:58 AM
2dem: я к ним пристал потому что они вплотную приближаются к моему РIII-650. Я лишь говорил про либу, которая сохраняет сложные структуры в одину цепочку, и без лишних движений восстанавливать эти сложные структуры из цепочки байтов. Если ты каждый раз для каждой структуры писал свою приблуду для записи и свою приблуду для считывания, действительно глупо.
	REAL 21 Jan 2003 11:30 AM
Мда... что ж хочется посочувствовать индивидуумам, которые в порыве своего ламеризма совершенно _необоснованно_ наезжают на xml (это и к автору статьи относится)
	glassy 21 Jan 2003 12:33 PM
2REAL: правильно, а лет так пять назад ты сочувствовал индивидуумам, необоснованно наезжавшим на html.
	DemonZla 21 Jan 2003 12:34 PM
бум надеяться Мс не испоганит XML своей виндою...
	dem 21 Jan 2003 3:02 PM
2glassy К сожалению наладонники приближаются к настольным только по частоте, но не по объему памяти.... 2DemonZla боюсь что сейчас прибежит РТО и начнет требовать урлы, но все-же скажу что MSXML не совместим с всеми рекомендациями w3c и в некоторых случаях их XML другими парсерами за такой не считается. (что-то с закрывающими тегами в схемах или еще где там..)
	dem 21 Jan 2003 3:09 PM
2glassy 21 января, 2003, 9:58 А ты знаешь другой способ? т.е. структуры по твоему что сами запишутся и считаются?
	DemonZla 21 Jan 2003 4:41 PM
dem, вот гады... опять всё испортят...
	glassy 22 Jan 2003 5:38 AM
2dem: http://engy.sourceforge.net/ss.png <-- анимированный bg. Там двигается все кроме фона и большого лого. Как это сделано http://engy.sourceforge.net/enaa.tar.gz Для создания дескрипторов использовался парсер
	dem 22 Jan 2003 9:00 AM
2glassy Может я чегоне понимаю, но разве у тебя там не разные функции для добавления (и чтения) разных объектов? (Видно мы о разном говорим)
	glassy 22 Jan 2003 1:10 PM
2dem: функции сохранения и считывания не я писал, просто их вызываю. А еслиговорить про инициализацию evas-объектов -- то так ведь с любыми данными надо что-то делать, на то они и данные.
	PTO - kruchkovkgb.ru 22 Jan 2003 4:47 PM
2 dem: аха попался :) какой версии MSXML не совместим - мне самому интересно, вдруг нарвусь
	glassy 23 Jan 2003 12:30 PM
http://russian.joelonsoftware.com/Articles/BacktoBasics.html
	dem 23 Jan 2003 12:53 PM
2РТО не скажу... 2glassy Согласен.... я сам часто ратую за это. Именно это мне и не нравится в OLE.
	maq 24 Jan 2003 10:08 PM
2dem есть способ делать большие хмлы - использовать SAX API. Т.е. когда ты не грузишь весь документ в память а последовательно его читаешь или записываешь. Это конечно менее удобно и не всегда возможно, но требует меньше памяти и процессорного времени
	Andrei 26 Jan 2003 12:27 PM
2maq: XML Stream support in .NET framework works pretty good in productive environmens and doesn't have intrinsic problems of SAX parser's push model...
	Andrei 28 Jan 2003 11:02 AM
2 glassy: (Можно и по русски когда родная клава под боком). Целиком и полностью согласен с уважаемым Joel, но он не написал о классах XmlTextReader and XmlTextWriter которые я как раз и имел ввиду в предыдущем посте. Эти классы при работе не используют DOM и все операции выполняются со Stream обектом. Тем более что я не буду голословным и скажу что по моим практическим данным все это делается очень быстро и с минимальным потреблением памяти (как раз столько что ты хранить данные текущего элемента с его аттрибутами). Кстати, напомню что memory allocation в .NET это по судеству сдвиг указателя в GC heap, т.е. очень быстрая операция. В нашем (ну очень большом коммерческом проекте) эта pull streaming model используется очень широко.
	Alexander - alexbibjneytx.com 10 Feb 2003 5:18 PM
Завидую я тем чувакам, которые не боятся писать статьи про то, о чем они не имеют понятия :)))) Как я понял, автор просто перепутал XML с HTML.
	Григорий Макеев 17 Feb 2003 11:32 PM
Да, это же надо... Первый раз я ТАКОЙ бред в ZDNet встречаю... Постеснялись бы, что-ли, выкладывать такую статью, а то уж совсем опростоволосились...