Перспективы XML

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Эллиотт Расти Хэролд (Elliot Rusty Harold), адъюнкт-профессор в области теории вычислительных машин, Polytechnic University

29.10.2009

Эллиотт Расти Хэролд рассказывает о том, какое будущее, по его мнению, ожидает XML.

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

Последнее уточнение представляется несколько забавным. В конце концов, разве Web как таковой существует не для публикации? Он ведь и создан-то был прежде всего для опубликования информации. Для чего же еще он может быть нужен? Много для чего. В последние три года мы стали свидетелями взрыва интереса к Web-приложениям, далеко выходящим за рамки привычных Web-сайтов. Текстовые процессоры, электронные таблицы, игры, средства для работы с диаграммами — все это и многое другое перекочевывает сегодня в окно браузера. И благодаря тому, что средства локального хранения данных Web-браузеров все в большей степени позволяют работать автономно, в текущем году эта тенденция только укрепится. Тем не менее XML по-прежнему прочно укоренен в Web 1.0-публикации и значение его все еще очень велико.

Мечты, мечты

В этом году должны сбыться кое-какие из давнишних мечтаний. Сбывается мечта Sun о приложениях, развернутых в сети, хотя в качестве языка для таких приложений выбран, как ни странно, не Java™, а JavaScript™. Это — весьма существенная упущенная возможность. Sun могла создать подобное еще 10 лет назад, но увы, ей не хватило для этого опыта, дальновидности или же заинтересованности в клиенте. То же, чем занимается Sun сегодня — это отчаянная (и заведомо безнадежная) игра в догонялки.

Сбывается в этом году и мечта Netscape о замене операционной системы браузером. В Netscape сумели предугадать эту тенденцию. Увы, для осуществления ее им не хватило то ли деловой смекалки, то ли художественного вкуса. Тем не менее Firefox и Mozilla Foundation, оба прямые наследники Netscape, являются сегодня ключевыми игроками в деле реализации этой прекрасной мечты.

Становится явью и кошмарный сон Microsoft® о молодом и более проворном сопернике, берущем над ней верх. Внимание этой компании было настолько поглощено Sun и Netscape, что она совершенно упустила из виду Google, исподтишка подрывавшего монополию Office и Windows. GMail, Google Docs и тому подобные приложения быстро сводят роль операционной системы к минимуму.

Само собой, операционная система по-прежнему необходима для запуска браузера, но потребителю становится все более и более безразлично, какая именно операционная система это будет — примерно как мало кого в последнее десятилетие интересовало, кем произведен тот или иной компьютер, коль скоро он поддерживает Microsoft Windows®. Теперь же никого не будет интересовать, кем разработана операционная система, коль скоро она позволяет запускать Google. Операционные системы становятся массовым товаром, точно так же, как это произошло с персональными компьютерами. Король-Windows не столько потерпел поражение, сколько стал никому не нужен, и Microsoft охраняет теперь ворота пустого дворца.

В начало

При чем же здесь XML?

Опция evalJSon() Да, я знаю об evalJSON(). Судя по некоторым виденным мной Ajax-приложениям, я знаком с ней лучше, чем кое-кто из разработчиков Ajax-приложений, упорно использующих eval() в течение многих лет после появления гораздо лучших возможностей.

Несмотря на широкую рекламу, XML имел ко всему вышеописанному довольно слабое отношение. Хотя на флаге мятежников начертано "асинхронный JavaScript + XML (Ajax)" и x в Ajax означает XML, никто особо не использует XML для чего-либо из перечисленного. Почти сразу же после того, как была предложена эта аббревиатура, Web-разработчики принялись заменять XML голым JavaScript-кодом, передавать его в виде данных, а затем исполнять посредством eval() — махнув рукой на соображения безопасности.

Проблема здесь, однако, не в форматах данных, а в API. Точнее говоря, в одном конкретном API — Document Object Model (DOM). Большинство разработчиков первым делом изучили DOM и с тех пор не интересуются ничем другим. Они не видят разницы между DOM и XML, а потому смешивают свое вполне обоснованное отвращение к DOM с совершенно безосновательным отвращением к XML. DOM — это не самый простой универсальный API; это самый плохой универсальный API. Худший API для обработки XML невозможно было бы придумать даже при желании. Но разработчики чрезвычайно неохотно учатся новому. За пределами Java-сообщества, где некоторое распространение получили JDOM и dom4j, лучшие альтернативы, такие как E4X и Amara XML Toolkit, остаются практически неизвестными и наталкиваются на активное противодействие. Гениальность JavaScript Serialized Object Notation (JSON) оказалась в то же время ее крупнейшим недостатком: будучи исполняемым JavaScript-кодом, JSON не требует от программистов изучать что-либо новое для своего запуска. Это, в свою очередь, снижает шансы принятия более безопасного формата передачи данных.

Часто используемые сокращения API: application programming interface HTML: Hypertext Markup Language SGML: Standard Generalized Markup Language W3C: World Wide Web Consortium XML: Extensible Markup Language

DOM — это камень на шее XML. Это единственное существенное препятствие к его более широкому применению в разработке программного обеспечения. XML продвинулся в программировании настолько далеко, насколько ему позволил этот 2000-фунтовый якорь. Если только консорциум World Wide Web (W3C) и производители браузеров не найдут DOM более разумную замену (а лучше — несколько разумных замен; недостатки DOM в значительной мере как раз и порождены попытками во всех случаях обойтись одним и тем же API), жизненный путь XML в разработке приложений подошел к концу — в особенности если говорить о Web-приложениях (которые все в большей степени становятся доминирующими). W3C необходимо принять во внимание потребности действующих разработчиков и при необходимости отказываться от плохих стандартов.

Так что же, XML умер? Нет, я верю, что ему предстоит сыграть блестящую и очень важную роль. И роль эта довольно слабо, если вообще, связана с разработкой классических или же Web-приложений. Чтобы понять, куда движется XML в 2008 и последующие годы, нам следует сперва вернуться в 1997 год и даже раньше — чтобы понять, откуда он вообще появился.

В начало

Истоки XML

Читателю следует иметь в виду, что XML вовсе не предназначался для использования в разработке приложений — во всяком случае, изначально. Ни один из ранних стандартов —XML 1.0, XPath, Extensible Stylesheet Language Transformation (XSLT), Namespaces in XML, Extensible Hypertext Markup Language (XHTML), DOM— не был ориентирован на нужды разработчиков. Если бы XML создавался для разработки ПО, он бы поддерживал списки, карты и типы данных — к чему в конце концов пришел JSON. Нет, XML предназначался для публикации; говоря конкретно, для публикации Web-страниц.

XML явился порождением на 20 лет более давней технологии, носившей название SGML. Приблизительно в то же время Кодд работал в IBM® над вопросом о том, как структурировать данные, разбив их на неупорядоченные фрагменты малого размера; Чарлз Голдфарб, Эдвард Мошер и Раймонд Лори, также в IBM, пытались решить задачу о структурировании больших упорядоченных документов, которые не могут иметь смысла в виде таблиц. Кодд работал над бизнес-данными наподобие инвентарных списков и документов финансового учета. Голдфарб, Мошер и Лори имели дело с такими документами, как ежегодные отчеты и авиационные технические руководства.

SGML предназначался для решения издательских задач: как составлять, хранить, обновлять, распечатывать, читать и находить нужную информацию в документах, которые могут занимать десятки тысяч страниц и предполагают использование самых разных платформ, процессоров, таблиц символов, естественных языков, операционных систем и компаний. С помощью SGML удалось достичь некоторого успеха в отношении правительственных и военных организаций, испытывавших такого рода потребности, а также небольшого количества технических издательств, в частности, O'Reilly, которым волею случая удалось воспользоваться плодами этой работы. Говоря же в общем, с точки зрения потребностей большинства людей — даже тех, кто занят в издательской сфере — SGML был чересчур сложен и громоздок.

Самая большая удача SGML стала и наибольшим его провалом. Речь идет об HTML. HTML задумывался как SGML-приложение, но почти никто из тех, кто занимался написанием браузеров, редакторов и Web-страниц, не знал о SGML ничего, кроме того, как расшифровывается эта аббревиатура (а многие не знали даже и этого). Само собой, возникали расширения языка, которые быстро свели на нет все возможные притязания на согласованность HTML с SGML. Даже существовавшие в то время немногочисленные и дорогостоящие SGML-средства не могли справиться с изысками живого языка HTML, характерного для Web образца примерно 1996 года.

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

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

Плохой ли, хороший ли, XML так или иначе предназначался для решения задач публикации: книг, руководств пользователя, и прежде всего — Web-страниц. Он не был оптимизирован и не планировался для использования в задачах разработки ПО, помимо издательских. Никто не предвидел и не рассчитывал, что XML будет применяться для конфигурационных файлов, процедурных вызовов, сериализации объектов, дампов баз данных и тому подобных задач, связанных с разработкой, поэтому не стоит удивляться, что он не всегда идеально для них подходит. И все же XML смог предложить разработчикам то, чего у них не было прежде — платформенно-независимый, не привязанный к языку, международно признанный формат данных с целым рядом высококачественных, бесплатных и легкодоступных парсеров. Благодаря такому неотразимому сочетанию программисты смогли легко пережить отсутствие таких типов данных, как int и float, а также таких фундаментальных структур, как списки и таблицы.

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

• Автор
• Публикатор
• Читатель

Инструмент читателя на сегодня полностью готов. Это браузер. Все основные браузеры поддерживают теперь XML. А вот что касается средств написания и опубликования, а также обеспечения связи между ними, то здесь все только начинается.

В начало

Создание документов

Прежде чем документ станет возможно опубликовать, его необходимо создать — и здесь битва окончена. XML победил. Все основные офисные комплексы по умолчанию сохраняют свои документы в ZIP-архивированном XML. Это делают Microsoft Office, OpenOffice, StarOffice, WordPerfect Office и Lotus® Notes®. Даже графические приложения, такие как Adobe® Illustrator®, могут теперь сохранять документы в XML. Из имеющихся исключений достоин упоминания прежде всего Apple-овский iWork, но и его присоединение к общей компании ожидается в нынешнем году.

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

Это важное нововведение не было оценено в полной мере — прежде всего потому, что XML, как и полагается, скрыт от пользователя. Среднестатистическому пользователю электронных таблиц нет никакого дела до того, каким именно образом Excel® размещает на диске постоянные данные. Вместе с тем, текстовая XML-структура позволяет третьей стороне с намного большей легкостью осуществлять реинжиниринг такого формата и взаимодействовать с приложением. Даже если словарь XML недостаточно хорошо документирован и грешит нелогичностями, как в случае OpenOffice XML, с ним все равно гораздо проще работать, чем с прежними невразумительными двоичными форматами. А если формат чуть более осмыслен и менее привязан к платформе и устаревшим приложениям — как, например, формат OpenDoc — иметь с ним дело оказывается еще проще.

В 2008 году нам предстоит стать свидетелями еще множества перепалок по поводу того, какой словарь XML использовать для офисных документов — с множеством аргументов с обеих сторон. Я подозреваю (хотя и не уверен), что Microsoft в феврале прекратит свои попытки добиться принятия OOXML в качестве стандарта ISO. Так или иначе, не нужно быть пророком, чтобы утверждать, что Microsoft Office будет продолжать уступать рынок OpenOffice, iWork и другим конкурентам.

И дело не в том, что Office плохой продукт (это неправда), и не в том, что его исходный код недоступен (это правда). Дело только лишь в том, что ему некуда двигаться, кроме как вниз. Ему больше некуда расти. Вопрос лишь в том, как низко и как быстро он упадет. Наиболее непосредственная угроза гегемонии Microsoft — это что правительства новых стран последуют примеру Нидерландов и Норвегии и узаконят OpenDoc и/или open source-решения. Не такой серьезной, но все же проблемой для Microsoft является увеличивающееся распространение PC-совместимых компьютеров по столь низким ценам, что Windows и Office составляют по меньшей мере половину стоимости всей системы. В какой-то степени Microsoft уже отреагировала на это, выпустив более дешевые редакции Office Student и Teacher, доступные сегодня всем, кто занимается преподавательской деятельностью, у кого в семье есть хотя бы один студент, кто посещал школу когда-либо в этом столетии или хоть раз уступил место в автобусе тому, кто, как ему показалось, был учителем. В то же время, являя собой великолепный пример правой руки, не знающей, что делает левая, Microsoft принимает дополнительные меры по борьбе с пиратством в отношении Office. И хотя это, вполне вероятно, снизит количество случаев неорганизованного пиратства, все больше пользователей станут в результате предпочитать open source-альтернативы.

Теперь, когда все офисные документы хранятся в XML, преобразование их из одного формата в другой становится чрезвычайно простым делом. В 2008 году мы отмечаем десятую годовщину, пожалуй, самой революционной технологии семейства XML — XSLT. В своей великолепной новой версии 2.0 она стала еще мощнее. В самом недалеком будущем конвертация конкурирующих форматов станет настолько простым делом, что большинству людей вообще окажется безразлично, в каком формате работать. Быть может, какие-то стили или макросы потеряются при переходе, но в большинстве документов такие вещи вообще не используются. Привязанность к конкретному вендору из-за формата становится гораздо менее серьезной проблемой.

Безусловно, наибольшее значение имеет не преобразование из OpenDoc в OOXML или наоборот. Куда важней обратное преобразование из OpenDoc или OOXML в XHTML. Средства экспорта в HTML что в OpenOffice, что в Microsoft Office — сущий кошмар. Компенсировать этот недостаток лучше при помощи сторонних разработчиков. Прежде всего найдите себе индивидуальных корпоративных разработчиков, которые бы создали публикационные шаблоны для своих сайтов. Это позволит обычным пользователям писать в привычном для них Microsoft Word, после чего загружать свои творения непосредственно в локальную систему управления контентом. Последняя также может включать в себя средства редактирования и просмотра. Поскольку вся теговая разметка генерируется машиной (человек при этом имеет дело с привычным ему графическим пользовательским интерфейсом), ее корректность достигается автоматически. К концу 2008 года достичь полной корректности всего Web еще не удастся, но дела с этим будут обстоять существенно лучше, чем сейчас.

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

Какими же средствами должен быть снабжен сервер, способный поддерживать создание документов с помощью традиционных офисных программ наподобие Word или OpenOffice Writer? И какими средствами будут передаваться данные от клиента к серверу? Именно здесь вступают в игру два наиболее значимых продукта, версии 1.0 которых вышли в 2007 году — Atom Publishing Protocol (APP) и XQuery.

В начало

Публикационный протокол Atom

Когда рассказываешь непрофессионалам, как писать для Web, традиционно сталкиваешься с двумя проблемами: как обучить их семантической разметке и как научить их пользоваться FTP. (Имейте в виду, что многие рядовые пользователи даже не умеют пользоваться стандартным диалоговым окном File — Open. Все свои файлы они хранят в папке "Мои документы" или на рабочем столе. Случайно поместив файл куда-нибудь еще, они теряются. Программисты, те, конечно, разбираются в соответствующих иерархиях, но многие пользователи не приучены к столь абстрактному мышлению.)

Текстовые процессоры, поддерживающие XML — такие, как OpenOffice и Microsoft Word — решают первую проблему. Публикационный протокол Atom (Atom Publishing Protocol, APP) решает вторую. APP станет для создания Web-документов тем же, чем HTTP стал для просмотра Web — источником стандартного протокола, который сможет использоваться многочисленными клиентами и серверами для обмена информацией без предварительных соглашений или общности концептуальной модели.

Независимые поставщики программного обеспечения могут создавать свои собственные подготовки документов, которые смогут обращаться к APP-сервисам на тех или иных сервисах. Это могут быть специально созданные редакторы или же плагины к таким продуктам, как Word или OpenOffice. Загрузка контента на сервер станет таким же простым делом, каким сегодня является сохранение файла на локальном жестком диске — а в некоторых случаях даже проще. Для создания нового документа нужно будет только знать, по какому URL его отправить, а также имя пользователя и пароль. (А Wiki-подобные сайты, вероятно, даже не будут требовать имени пользователя и пароля.) А для редактирования документа понадобится только его URL.

В начало

Куда все это поместить?

Итак, вы знаете теперь, как вы будете писать на XML в 2008 году (в Word или OpenOffice) и как будете отправлять написанное на сервер (с помощью APP). Осталось выяснить, куда же поместить этот чудо-XML.

Традиционно на этот вопрос имеется два ответа. Первый — сохранить XML-файл в файловой системе, второй — внедрить его в крупный бинарный объект (Binary Large Object, BLOB) в реляционной базе данных. Оба эти варианта ущербны; ни один из них как следует не работает в случае Web-сайтов.

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

Реляционные базы данных — это большие хранилища для маленьких кусочков информации, для которых не установлен какой-либо определенный порядок и которые особо не дублируют друг друга. Но ни одна из этих характеристик не верна в отношении XML. Хотя всякая реляционная таблица может быть с легкостью преобразована в XML-документ (просто сделайте каждую строку элементом, а каждое поле — атрибутом или дочерним элементом), обратное утверждение неверно. Многие XML-документы отличаются существенной упорядоченностью, содержат значимые пустые места, содержимое разных типов, повторяющиеся, но не тождественные элементы, непредсказуемые вложенные элементы и прочие составляющие, из-за которых реляционные таблицы оказываются неподходящим способом хранения данных. Web-страницы, в частности, HTML- и XHTML-страницы, обладают всеми перечисленными характеристиками. Разумеется, HTML- и XHTML-страницы можно хранить в реляционных базах данных, — хотя все-таки MySQL используется немного для другого — но в результате вы не получите ни удобства, ни быстроты. Если вы разобьете документы на множество маленьких фрагментов, вы сможете осуществлять среди таких данных поиск, выбирать нужное и реорганизовывать их. Вот только приемлемой производительности вы сможете добиться только ценой больших затрат. Настоящим кошмаром для вас станут также и поддержка работоспособности системы и ее развитие: представьте себе полустраничные SQL-запросы с весьма и весьма нетривиальной логикой для решения несложных задач, к которым SQL просто не приспособлен.

Альтернативный подход — хранить документы в BLOB. Это простой и быстрый способ. Но в этом случае вы утратите возможность выбрать только определенную часть данных или скомбинировать различные документы. Логика приложения передается PHP, Ruby или какой-нибудь другой структуре на стороне сервера. База данных в таком варианте использования — это почти та же файловая система, с разве что чуть лучшими изоляционными характеристиками.

В чем действительно есть потребность, так это в базах данных, приспособленных для работы с иерархическими структурами типичных Web-документов, а не конфликтующих с ними. Такие базы данных теперь существуют в большом количестве , они стабильны и готовы к использованию. Среди самых простых назовем все лучше и лучше выглядящие eXist и Berkeley DBXML. Располагающиеся на другом конце диапазона мощные и дорогие XML-базы вроде Mark Logic будут продолжать обращать в свою веру крупных издателей, способных позволить себе соответствующие расходы. Что же до гибридных решений, таких как IBM DB2® 9 pureXML™, то они будут способствовать переходу на XQuery заказчиков, использующих как документы, так и табличные данные.

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

Выход в свет обновленной версии XQuery приближается семимильными шагами. Вряд ли она будет полностью готова в 2008 году, но и уже сделанное вполне достойно применения — если пользователи не будут против того, чтобы слегка корректировать свой код после каждого нового выпуска. В течение года эта ситуация будет улучшаться.

Наконец, в 2008 году мы станем свидетелями выхода в свет javax.xml.xquery. Это стандартный API для связывания Java-программ с механизмами и базами данных XQuery. Считайте его чем-то вроде JDBC для XQuery. Он дает возможность делать XQuery-вставки в Java-коде. Вряд ли он станет стандартной составляющей библиотеки классов Java до выхода в свет Java 7 в 2009 г., но некоторые продукты уже поддерживают такую возможность, а в будущем их число возрастет.

В начало

Чего еще не хватает?

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

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

                
 <data xmlns="http://www.w3.org/data">
  <list>
    <string>Foo</string>
    <int>17</int>
    <year>1999</year>
  <list>
  <map>
   <entry>
     <string>Boston</string><string>Red Sox</string>
   </entry>
   <entry>
     <string>New York</string><string>Yankees</string>
   </entry>
  </map>
</data>

Затем представьте себе, что вы написали несколько простых библиотек на Java, JavaScript, Python, Perl, Ruby и других языках, которые могут осуществлять парсинг таких документов в собственные структуры данных этих языков. Можно ли заново изобрести JSON, но на сей раз без проблем с безопасностью и с той степенью гибкости, которую способен обеспечить XML? Не перевелись ли еще в мире хакеры?

Ресурсы

• Оригинал статьи "The future of XML" (EN)
  
  
• Работайте с документами ODF и Microsoft Office 2007 с помощью DB2 9 pureXML (Chris C. Gruber, developerWorks, август 2007 г.): научитесь хранить и изменять назначение данных с помощью PHP PDO и XQuery, используя IBM DB2 9.
  
  
• Управляйте собранием медиа-документов с помощью Atom Publishing Protocol (Nicholas Chase, developerWorks, апрель 2007 г.): соедините формат синдикации Atom с протоколом публикации Atom для создания Web-хранилища медиа-документов. (EN)
  
  
• Введение в XQuery (Howard Katz, developerWorks, январь 2006 г.): ознакомьтесь с ранним обзором W3C-стандарта языка запросов XML. (EN)
  
  
• Зачем нужны XForms? (Elliotte Rusty Harold, developerWorks, октябрь 2006 г.): Годится ли это для вас? Ознакомьтесь с XForms как с решением, примите во внимание его интернационализацию, доступность и независимость от конкретных устройств. (EN)
  
  
• XML 2007: ежегодный обзор (Elliotte Rusty Harold, developerWorks, декабрь 2007 г.): Оглянитесь на XML в 2007 году вместе с автором этой статьи. (EN)
  
  
• Техническая библиотека XML: в разделе XML на developerWorks вы найдете множество технических статей, ценных советов, учебников, стандартов и выпусков IBM Redbooks. (EN)
  
  
• Технические события и Web-трансляции на developerWorks: следите за развитием технологии.(EN)
  
  
• Магазин технической книги: ищите здесь книги по этой и другим техническим темам.(EN)
  
  

• XML-СУБД eXist: эпоэкспериментируйте с XQuery в этой СУБД с открытым кодом, полностью построенной на XML-технологии. С помощью eXist можно хранить XML-данные согласно модели данных XML и эффективно индексировать их посредством XQuery(EN).
  
  
• Ознакомительные версии ПО IBM: используйте в следующем проекте разработки ознакомительные версии программных продуктов IBM, которые можно загрузить непосредственно с developerWorks.(EN)
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Блоги на developerWorks: посетите эти блоги и присоединитесь к сообществу developerWorks.

Об авторе

		Эллиотт Расти Хэролд (Elliotte Rusty Harold) - адъюнкт-профессор в области теории вычислительных машин и систем Политехнического университета в Бруклине. Он преподает технологию Java и объектно-ориентированное программирование.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало