Синхронизация в реальном времени данных xml между приложениями

Изобретение относится к компьютерной технике, конкретнее к системе синхронизации данных. Техническим результатом является обеспечение возможности бесконфликтного сохранения данных, ассоциированных с документами, за счет синхронизации. Система содержит: внутренний потребитель данных, который конфигурирован для создания и редактирования документа, и взаимодействия со структурированными элементами данных, внутренний стек отмены, ассоциированный с внутренним потребителем данных, внешние потребители данных, которые конфигурированы для взаимодействия со структурированными элементами данных, множество внешних стеков отмены, причем каждый внешний стек отмены ассоциирован с каждым внешним потребителем данных, хранилище данных, которое конфигурировано для хранения структурированных элементов данных, причем хранилище данных содержит: API-брокер, который конфигурирован для взаимодействия с внешними потребителями данных и внутренним потребителем данных. 3 н. и 16 з.п. ф-лы, 8 ил.

 

Предпосылки изобретения

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

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

Сущность изобретения

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

Одно или более хранилищ данных поддерживаются отдельно от основного запоминающего устройства (ЗУ) презентации в документе для хранения, связывания и для разрешения использования произвольных данных, которые ассоциированы с генерированным компьютером документом, между множеством потребителей данных. Данные для структурирования информации, ассоциированной с документом, такие как метаданные документа, поддерживаются в хранилище данных, где поддерживаются соотношения между различными частями данных. Хранилище данных предоставляет интерфейсы программирования приложений (API) для различных частей данных в хранилище данных для разрешения различным потребителям данных получать доступ и работать с одной или более частями данных в реальном времени. Множество потребителей данных могут получать доступ и редактировать те же самые части данных одновременно, и любые конфликтующие изменения в отношении данной части данных разрешаются. Каждый потребитель данных может принимать или отклонять изменения, а также выполнять дополнительные изменения побочных эффектов как результат исходного изменения. Таким способом данные могут быть синхронизированы в реальном времени среди потребителей данных.

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

Краткое описание чертежей

Фиг.1 - примерная вычислительная архитектура для компьютера;

Фиг.2 - блок-схема, иллюстрирующая соотношение между одним или более клиентских приложений и одним или более хранилищ данных и контентом хранилищ данных;

Фиг.3 - блок-схема, показывающая взаимодействие между внутренними и внешними потребителями данных с хранилищами данных XML;

Фиг.4 - иллюстрация примера синхронизации реального времени;

Фиг.5 - иллюстрация взаимодействия между двумя клиентами и хранилищем данных XML;

Фиг.6 - блок-схема, показывающая взаимодействие между двумя внешними потребителями данных и изменением в хранилище данных XML;

Фиг.7 - процесс, связанный с множеством изменений побочных эффектов; и

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

Детальное описание

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

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

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

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

Термин «тег» относится к символам, вводимым в документ, который ограничивает элементы в документе XML. Каждый элемент может иметь не более двух тегов: начальный тег и конечный тег. Возможно иметь пустой элемент (без контента), и в этом случае допустим один тег.

Термины «язык разметки» или «ML» относятся к языку для специальных кодов в документе, которые определяют, как интерпретировать части документа приложением. В файле текстового процессора язык разметки определяет, каким образом текст должен быть сформатирован или скомпонован.

Термин «элемент» относится к базовому блоку документа XML. Элемент может содержать атрибуты, другие элементы, текст и другие области контента для документа XML.

Контент XML между тегами рассматривается как «потомок» элемента. Следовательно, другие элементы, вложенные в контент элемента, называются «дочерними элементами» или «дочерними узлами» элемента. Текст, встроенный прямо в контент элемента, рассматривается как «дочерние текстовые узлы» элемента. Совместно дочерние элементы и текст в элементе образуют «контент» элемента.

Термин «атрибут» относится к дополнительному свойству, установленному на конкретное значение и ассоциированному с элементом. Элементы могут иметь произвольное число настроек атрибутов, ассоциированных с ними, включая их отсутствие. Атрибуты используются для ассоциирования дополнительной информации с элементом, который не будет содержать дополнительных элементов или будет интерпретироваться как текстовый узел.

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

Термин «изменение побочного эффекта» относится к изменению, которое делается в ответ на другое изменение.

Термин «документ» может состоять из произвольного XML, который описывает свойства, которые определены в ассоциированном типе контента, а также других языков разметки, которые могут использоваться для описания действительного наружного содержания документа.

Термин «хранилище данных XML и/или хранилище данных» относится к контейнеру в документе, таком как документ текстового процессора, документ электронной таблицы, документ представления слайдов и т.д., который предоставляет доступ для хранения и модифицирования данных (например, в формате XML), сохраненных в документе, когда файл открыт. Дополнительное определение хранилища данных XML предоставлено ниже со ссылкой на фиг.2.

Со ссылкой на фиг.1, примерная система для реализации изобретения включает в себя вычислительное устройство, такое как вычислительное устройство 100. В самой основной конфигурации вычислительное устройство 100 в типовом случае содержит, по меньшей мере, один процессорный блок 102 и системную память 104. В зависимости от точной конфигурации и типа вычислительного устройства системная память 104 может быть энергозависимой (такой как ОЗУ), энергонезависимой (такой как ПЗУ, флэш-память и т.д.) или некоторой комбинацией обоих типов. Системная память 104 в типовом случае содержит операционную систему 105, одну или более прикладных программ 106 и может включать в себя программные данные 107. В одном варианте осуществления прикладная программа 106 может включать в себя приложение 120 текстового процессора. Эта базовая конфигурация иллюстрируется на фиг.1 компонентами в пределах пунктирного контура 108.

Вычислительное устройство 100 может содержать дополнительные признаки или функциональные средства. Например, вычислительное устройство 100 может также содержать дополнительные ЗУ данных (съемные или несъемные), такие, например, как магнитные диски, оптические диски, магнитная лента. Такое дополнительное ЗУ иллюстрируется на фиг.1 съемным ЗУ 109 и несъемным ЗУ 110. Компьютерные носители для хранения данных могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым методом или технологией для хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули и другие данные. Системная память 104, съемное ЗУ 109 и несъемное ЗУ 110 являются примерами компьютерных носителей для хранения данных. Компьютерные носители для хранения данных включают в себя, без ограничения указанным, ОЗУ, ПЗУ, ЭСППЗУ, флэш-память и другие технологии памяти, ПЗУ на компакт-дисках (CD-ROM), цифровые многофункциональные диски (DVD) или другие устройства памяти на оптических дисках, магнитные кассеты, магнитную ленту, устройства памяти на магнитных дисках или другие магнитные запоминающие устройства, или любые другие носители, которые могут быть использованы для хранения полезной информации, и к которым может обращаться вычислительное устройство 100. Любые такие компьютерные носители для хранения данных могут быть частью устройства 100. Вычислительное устройство 100 может также включать в себя устройства ввода 112, такие как клавиатура, мышь, перо, устройство речевого ввода, устройство сенсорного ввода и т.д. Также могут быть включены устройства 114 вывода, такие как дисплей, динамики, принтер и т.д. Эти устройства хорошо известны в технике и не требуют детального описания.

Вычислительное устройство 100 может также содержать коммуникационные соединения 116, которые позволяют устройству осуществлять связь с другими вычислительными устройствами 118, например, через сеть. Коммуникационные соединения 116 являются примером коммуникационных сред. Коммуникационные среды в типовом случае воплощают считываемые компьютером команды, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущее колебание или другой транспортный механизм, и включают в себя любую среду доставки информации. Термин «модулированный сигнал данных» означает сигнал, у которого одна или более из его характеристик установлена или изменяется таким способом, чтобы кодировать информацию в сигнале. В качестве примера, но не ограничения, коммуникационные среды включают в себя проводные среды, такие как проводные сети или прямые проводные соединения, и беспроводные среды, такие как акустические, радиочастотные и инфракрасные и другие беспроводные среды. Термин «машиночитаемые носители», как он используется в настоящем документе, включает в себя как носители для хранения данных, так и коммуникационные среды.

Ряд программных модулей и файлов данных могут быть сохранены в системной памяти 104 вычислительного устройства 100, включая операционную систему, подходящую для управления работой соединенного в сеть персонального компьютера, такую как операционная система WINDOWS от корпорации MICRОSOFT (Redmond, Washington). Системная память 104 также может хранить один или более программных модулей, таких как приложение 120 текстового процессора, и других, описанных ниже. Приложение 120 текстового процессора действует для предоставления функциональности для создания, редактирования и обработки электронных документов.

Согласно одному варианту осуществления изобретения приложение 120 текстового процессора содержит программу WORD от корпорации MICRОSOFT. Однако понятно, что могут быть использованы другие приложения текстовых процессоров от других производителей. Иллюстрация приложения текстового процессора приведена только в качестве примера и не ограничивает другие типы приложений, которые могут создавать документы и воздействовать на них. Например, другие прикладные программы 106, которые способны обрабатывать различные формы контента (например, текст, изображения, картинки и т.д.), такие как прикладные программы электронных таблиц, прикладные программы баз данных, прикладные программы представлений слайдов, прикладные программы рисования или автоматизированные прикладные программы и т.д., применимы равным образом. Примером прикладной программы 106, которая создает и обрабатывает различные документы разных типов, является OFFICE от корпорации MICRОSOFT.

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

На фиг.2 показана блок-схема, иллюстрирующая соотношение между одним или более клиентских приложений и одним или более хранилищ данных и контентами хранилищ данных. Описывая в обобщенном виде, одно или более хранилищ данных поддерживаются отдельно из основного ЗУ презентации в документе для хранения, связывания или для разрешения использования произвольных данных среди потребителей данных, которые ассоциированы с созданным компьютером документом. Данные для структурирования информации, ассоциированной с документом, такие как метаданные документа, поддерживаются в хранилище данных, где поддерживаются соотношения между различными частями данных. Хранилище данных открывает интерфейсы программирования приложений (API) к различным частям данных в хранилище данных, чтобы позволить различным приложениям получать доступ и обрабатывать одну или более частей данных. Как использовано в настоящем документе, термины «потребители данных», «приложения» и «процессы» могут использоваться взаимозаменяемым образом, если только из контекста явно не следует иное.

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

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

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

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

Хранилище 208 данных является хранилищем данных документа для хранения одной или более частей структурированных данных, ассоциированных с одним или более типами данных, ассоциированных с данным документом. Хотя показано только одно хранилище данных, может использоваться более одного хранилища данных. Метаданные 225 (элемент структурированных данных) могут включать в себя структуру данных XML и ассоциированные данные для первой части метаданных, ассоциированных с документом. Например, метаданные 1 (225) могут включать в себя данные структуры XML (например, теги данных, теги имени и т.д.), перечисляющие автора документа, дату создания документа, дату последнего изменения/сохранения документа и т.д. Метаданные 2 (230) (элемент структурированных данных) могут включать в себя данные структуры XML (теги) и ассоциированные метаданные, представляющие вторую часть метаданных, ассоциированных с документом. Метаданные 1 и метаданные 2 приведены только для примера, но не в качестве ограничения различного числа разных типов данных, которые могут поддерживаться в хранилище 208 данных в связи с данным документом. Например, как описано здесь, произвольные данные могут быть структурированы и добавлены в документ посредством одного или более приложений программного обеспечения, как это желательно разработчикам решений или пользователям, имеющим доступ к данным документа.

Файл 240, 245 схемы может факультативно присоединяться к каждой части данных, сохраненных в хранилище 208 данных, для определения синтаксиса или правил подтверждения подлинности, ассоциированных с данными XML, применимыми к каждой части данных 225, 230. Файлы схемы XML обеспечивают способ описания и подтверждения данных в среде XML. Файл схемы устанавливает, какие данные разметки XML, включая элементы и атрибуты, используются для описания контента в документе XML, и файл схемы определяет синтаксис разметки XML, включая то, где каждый элемент разрешен, какие типы контента разрешены в элементе, и какие элементы могут появляться в других элементах. Использование файлов схемы гарантирует, что документ (или индивидуальная часть данных) структурирован непротиворечивым и предсказуемым образом. Файлы 240, 245 схемы могут быть созданы пользователем и в общем поддерживаться ассоциированным языком разметки, таким как XML.

Эта схематизация документа позволяет хранилищу данных обеспечивать возможность «гарантировать» структурную подлинность документа путем отклонения любых изменений, которые нарушают данную схему файла на уровне хранилища данных. Согласно одному варианту осуществления хранилище 208 данных использует модуль 260 подтверждения правильности схемы для подтверждения правильности структуры XML, добавленной к конкретной части данных, или изменений, внесенных в конкретную часть данных, по отношению к ассоциированному файлу схемы. Например, если создатель или редактор документа выполняет структурные изменения XML в конкретной части данных, например, метаданных 1, причем редактор добавляет или удаляет заданный тег XML, то хранилище 208 данных будет использовать модуль 260 подтверждения правильности схемы для проверки структурных изменений XML по отношению к ассоциированному файлу схемы, чтобы гарантировать действительность изменения. Если изменение не действительно, то для редактора может быть сформировано сообщение об ошибке. Понятно, что такой контроль структуры XML, примененный к конкретной части данных, обеспечивает структурную непротиворечивость и предсказуемость, которые особенно важны для обеспечения возможности приложениям клиента и третьей стороны взаимодействовать с ассоциированными данными. Любой потребитель данных может обеспечить схему, которая может быть использована для проверки правильности данных.

Хранилище 208 данных обеспечивает один или более интерфейсов программирования приложений (API) 270, к которым могут обращаться клиентские приложения 205 (например, приложения текстовой обработки, приложения электронных таблиц, приложения презентации слайдов и т.д.), а также приложения 210, 215 третьей стороны через модели объектов (ОМ) соответствующих приложений 210, 215. Эти API позволяют клиентским приложениям и приложениям третьей стороны загружать любой существующий файл XML в хранилище 208 данных конкретного документа, тем самым обеспечивая, что данные теперь становятся частью документа и будут перемещаться внутри этого документа в течение его срока жизни (например, во время открытия/редактирования/сохранения/ переименования и т.д.) или до тех пор, пока данные не будут удалены из хранилища. Соответственно одному варианту осуществления изобретения, данные в хранилище данных доступны в их формате XML, даже если исходное приложение для конкретной части данных 225, 230 закрыто или иным образом не доступно. То есть доступ к конкретной части данных 225, 230 может быть получен через набор API. Как описано ниже, API также позволяют приложениям клиента и третьей стороны выполнять изменения в данных разметки XML, применительно к элементам данных 225, 230.

Как только данные 225, 230 XML загружены в хранилище данных для ассоциирования с документом 220, ими можно манипулировать, как стандартным XML

с использованием интерфейсов хранилища данных, предназначенных для предоставления подобных методов для существующих интерфейсов редактирования XML, чтобы сбалансировать существующие знания разработчиков стандарта программирования XML. Это позволяет пользователям выполнять стандартные операции XML над данными XML, добавленными к хранилищу данных для документа, такими как добавление элементов и атрибутов, удаление элементов и атрибутов, изменение значения существующих элементов и атрибутов и считывание значений любой существующей части ассоциированного дерева XML. С использованием этих стандартных операций XML решения могут хранить структурированные комплексные метаданные с документом. Например, приложение 215 третьей стороны может быть написано для нахождения и извлечения имен авторов документов и дат создания документов из ряда документов путем считывания метаданных 225, добавленных к хранилищу 208 данных для каждого документа. Примерное приложение третьей стороны может быть приложением, запрограммированным для создания списка имен авторов документов и дат создания документов из всех документов, созданных конкретной организацией. В соответствии с вариантами осуществления настоящего изобретения приложение третьей стороны может использовать структуру XML, примененную к метаданным, для эффективного нахождения и извлечения желательных данных. Например, приложение третьей стороны может быть написано для анализа структуры XML файла метаданных для нахождения тегов XML, таких как <docauthor> (автор документа) <doccreationdate> (дата создания документа) для получения и использования данных, связанных с этими тегами. Можно понять, что приведенное выше является только примером множества способов, которыми одно или более приложений может взаимодействовать со структурированными данными, которые ассоциированы с документом в хранилище 208 данных.

Кроме того, хранилище 208 данных обеспечивает любое число API 270 для любой индивидуальной части данных XML 220, 225, 230 (также известных как элемент хранения) для обеспечения возможности множеству приложений 205, 210, 215 работать с одними и теми же частями данных. Например, различные решения, такие как клиентское приложение (например, приложение текстовой обработки), и решения приложений третьей стороны (например, описанные выше приложения третьей стороны), могут работать с одним и тем же набором свойств документа (например, свойствами, содержащимися в файле метаданных 2 230). Используя хранилище 208 данных, каждое из этих приложений получает отдельный доступ к желательным данным XML 230 через свой собственный API 270 с хранилищем данных для обеспечения возможности каждому приложению осуществлять информационный обмен с данными через своего собственного администратора объектов, без необходимости учитывать сложность, обусловленную присутствием множества потребителей данных, получающих доступ к той же самой части данных.

Для того чтобы позволить этому множеству приложений 205, 210, 215 получать доступ к тем же самым данным, хранилище 208 данных уведомляет каждое их этих приложений, если какая-либо часть данных XML была изменена другим приложением, так что данное приложение может ответить на это изменение (как внутренним образом к своему собственному процессу, так и внешним образом посредством других изменений тех же самых данных). Если одно приложение запрашивает изменение для конкретного элемента данных, этот запрос автоматически посылается ко всем другим приложениям, чтоб позволить им принять решение, каким образом отвечать или отвечать ли на запрошенное изменение. Согласно одному варианту осуществления это выполняется путем разрешения каждому приложению регистрировать «прослушивание» любой части данных XML, с которой оно имеет интерфейс, так что конкретное решение приложения/программа принимает только те сообщения, которые соответствуют его собственной логике. Например, одному типу приложения 210 может быть желательным регистрировать прослушивание всех изменений, выполненных для конкретных данных XML, чтобы обеспечить детальные логические возможности бизнеса для решения третьей стороны, но другому типу приложения 215 может быть желательным прослушивать только изменения одного или двух конкретных элементов XML в тех же самых данных, поскольку его логика безразлична к изменениям в любых других частях данных XML.

Согласно этому варианту осуществления множество приложений 205, 210, 215 могут обращаться и редактировать одни и те же части данных документа, и любые конфликтующие изменения в конкретной части данных разрешаются. Например, «побочные эффекты» для любого данного изменения могут быть выполнены, если одно изменение посредством одного приложения вызывает изменение побочного эффекта другим приложением. Например, первое приложение 210 может иметь задачу извлечения имен компаний из одного или более элементов данных 225, 230, ассоциированных с конкретным документом, для преобразования этих имен в символы акций, если доступно, для составления списка символов акций компании, относящегося к данному документу. Если второе приложение 215 вызывает добавление имени конкретной компании в конкретной части метаданных или его изменение, например, изменение имени компании с «компании АВС» на «компанию XYZ», то первое приложение может прослушать это изменение для автоматического обновления своего списка символов акций для включения символа акций для «компании XYZ» вместо «компании АВС». Кроме того, такие изменения и любые ассоциированные побочные эффекты могут быть скомплектованы хранилищем 208 данных так, что отмена одного или более изменений реверсирует все связанные изменения.

Фиг.3 иллюстрирует блок-схему, показывающую взаимодействие между внутренними и внешними потребителями данных с хранилищами данных XML. Как показано, система 300 содержит документ 315, хранилище 302 данных, уровень 304 презентации, хранилища 1-N (306) XML в хранилище 302 данных, каждое из которых содержит хранилище ошибки и хранилище отмены, хранилище 308 глобального изменения, факультативное глобальное хранилище 310 отмены, внутренний брокер 312, который связан с внутренними потребителями 1-N 314 данных, внешнее хранилище 320 XML и внешний брокер 316, который связан с внешними потребителями 1-N 318 данных.

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

Как описано выше, программный доступ к этим данным обеспечивается через API, который может быть использован, когда документ редактируется, предоставляя стандартный механизм, знакомый разработчикам решения, через который к этой информации можно обращаться и изменять ее программным образом, когда документ открыт. Соответственно одному варианту осуществления этот программный доступ предназначен для имитации стандартных интерфейсов XML. Используя API, данные можно добавлять/удалять при выполнении приложения, такого как текстовая обработка; данные можно заполнять в элемент хранилища (часть в хранилище данных); данными можно манипулировать с использованием стандартных конструкций XML; схемы могут быть ассоциированы с любыми произвольными данными XML в хранилище данных; схемы можно добавлять, удалять, изменять после ассоциирования с элементом хранилища данных; и изменения XML могут быть сообщены любым прослушивающим клиентам. Как иллюстрируется, API содержит внешний брокер 316, который обеспечивает интерфейс для внешних потребителей 318 данных, и внутренний брокер 312, который обеспечивает интерфейс для внутренних потребителей 314 данных, которые взаимодействуют с хранилищем 302 данных.

Манипуляции в отношении хранилища 302 данных могут происходить в реальном временим. Как описано выше, хранилища 302 и 306 данных могут содержать один или более типов данных. Например, одна компания может иметь одно хранилище данных, которое используется для хранения всех различных типов данных, которые желательно хранить в одном хранилище 302 данных, в то время как другой компании может быть желательно хранить данные разных типов данных в разных хранилищах данных.

Потребитель данных (внутренний 314 и/или внешний 318) может регистрировать события, которые относятся к действиям относительно данных в хранилищах данных. Например, потребитель данных может регистрироваться для приема события, когда любой тип изменения осуществляется для одного или более хранилищ данных. Другой потребитель данных может регистрироваться для изменений, которые происходят для некоторого элемента или набора элементов в хранилище данных. Обычные события включают в себя добавление элемента, изменение элемента, удаление элемента из одного из хранилищ данных. Когда событие происходит, то каждый потребитель данных, который зарегистрировался, может реагировать на изменение, причем состояние хранилищ данных поддерживается соответственно. Во многих случаях потребитель данных не будет выполнять никаких действий, когда произошло изменение. В других случаях потребитель данных будет выполнять некоторое(ые) действие(я) в ответ на событие. Например, потребитель данных может выполнить некоторые другие изменения в хранилище данных в ответ на такое изменение, например, в ответ на изменение названия, обновляя заголовки в документе. Потребитель данных может также выполнить некоторые другие операции, которые не влияют на документ. Например, если введен символ акций (аббревиатура ценной бумаги), то потребитель данных может извлечь данные, которые ассоциированы с этим символом акций, даже если все извлеченные данные могут не отображаться в документе на уровне презентации. Потребитель данных может также отклонить изменение с использованием своей собственной логики проверки правильности. Например, если потребитель данных 1 получает изменение, которое он не принимает, то потребитель данных может возвратить брокеру флаг, указывающий, что изменение не принято. Если изменение не принято, то для изменения выполняется откат назад, вместе с любыми побочными эффектами, так что изменение не возникает вообще. Каждое хранилище 306 XML может использовать свое хранилище отмены для отмены изменений, которые оно выполнило. Альтернативно, глобальное хранилище 310 отмены может использоваться, чтобы отменить изменения, выполненные в хранилищах данных. Представим, что есть три потребителя данных, которые заинтересованы в том, что происходит со свойствами документов, так что каждый из этих потребителей данных зарегистрировался для получения события, относящегося к изменению свойств. Когда изменение выполняется, хранилище данных определяет каждого потребителя данных, который зарегистрирован, и информирует каждого из них об изменении в предварительно определенном порядке. Каждый потребитель данных, в свою очередь, может выполнить некоторое действие в ответ на изменение. Если изменение или любое из изменений, выполненное зарегистрированными потребителями данных как результат данного изменения, не принимаются любым одним из потребителей данных, то все изменения, относящиеся к первоначальному изменению, отменяются.

Уровень 316 API внешнего брокера обеспечивает доступ к хранилищу 302 данных для внешних потребителей 318 данных и обеспечивает клиентам третьей стороны возможность взаимодействовать с хранилищем 302 данных точно так, как внутренние потребители данных, которые связаны с приложением, взаимодействуют с хранилищем 302 данных. Каждое из хранилищ 306 данных XML в хранилище 302 данных снабжено уникальным ID для целей идентификации. Это помогает в нахождении хранилищ 306 данных XML.

В любой момент времени потребитель данных может добавить схему, которая используется для подтверждения действительности данных в хранилище данных. Если схема добавлена, и потребитель данных пытается изменить какие-либо из данных, то хранилище данных определяет, согласовано ли изменение с предусмотренной схемой. Как только схема добавлена, брокер становится подтверждающим действительность объектом.

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

Например, если пользователю потребовалось бы создать титульный лист к записке по исследованию собственного капитала компании в приложении, которое не имело возможностей XML, то извлечение полезных данных (например, имени компании, символа акций, расчета ставок) потребовало бы использования модели объекта приложения, которая тесно связана с форматом презентации документа. Это необходимым образом означало бы, что результирующая логика решения была бы также связана с форматом презентации документа и обусловила бы неуспех, если бы эта презентация была изменена. Например, если код ожидает, что символ акции должен быть в столбце 3, строке 2 первой таблицы, то добавление новой строки/столбца нарушило бы эту логику. В приложениях с возможностями XML, однако, этот код может теперь связываться со структурой собственных данных потребителя, исключая необходимость в том, чтобы логика связывалась с презентацией. Та же самая логика могла бы выполнять поиск контента узла XML <stockSymbol/> и находить его, если он существует в документе, чтобы редактировать его, даже если контекстная презентация существенным образом изменилась.

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

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

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

Как описано здесь, данные XML, которые ассоциированы с документом, могут быть сохранены отдельно от любого документа конкретного приложения в центральном хранилище 302 данных XML. Множество сред может быть создано для презентации/редактирования одной части данных XML. Выражения этих данных автоматически синхронизируются через их связи с теми же самыми данными в хранилище данных XML. Как таковые, множество приложений могут одновременно отображать те же самые базовые данные XML. Это означает, что пользователю предоставлена возможность редактировать те же самые данные в приложении, которое является «наилучшим инструментом для задачи». Например, форма редактирования информации метаданных, внешнее представление документа текстовой обработки для редактирования секций свободной формы данных и т.д. Это также означает, что пользователь может редактировать данные во множестве приложений, как это желательно. Если одна и та же информация представляется во множестве приложений, пользователь может редактировать данные в любой из них, как желательно, на основе их текущего контекста редактирования.

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

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

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

Хранилище отмены может быть глобальным хранилищем 310 отмены, и/или хранилища отмены могут быть включены в каждое хранилище XML. Запросы изменений каждого потребителя данных могут конкатенироваться в единый стек отмены, такой как хранилище 310 отмены, который комбинирует каждое изменение со всеми связанными изменениями, так что каждое может быть отменено как блок. Это позволяет всем клиентам запрашивать «отмену» последнего полного изменения, сохраняя весь документ в известном «хорошем» состоянии.

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

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

Всякий раз, когда хранилище данных уведомляет потребителя данных об изменении, потребитель данных может: не делать ничего и принять изменение; запросить одно или более изменений побочных эффектов и отклонить изменение. Изменения побочных эффектов в основном связаны с добавлением логики, которая инициирует изменения в ответ на другие изменения, которые выполнены в отношении хранилища данных. Например, потребитель данных, который использует записку по исследованию собственного капитала компании, может пожелать принимать уведомления, когда узел <stockSymbol/> в хранилище данных изменяется, и в ответ на изменение направлять данные в web-сервис и обновлять поддерево <stockData/>, которое находится в хранилище данных.

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

Если потребитель данных (314 и/или 318) запрашивает изменение в хранилище 302 данных XML, это изменение может быть отклонено по разным причинам, включая: изменение является недействительным (например, XML некорректно сформирован); изменение было отклонено некоторой логикой у потребителя данных и т.п.

Некоторые потребители данных могут сохранять свою собственную версию данных в хранилище 320, которое поддерживается отдельно от хранилища 302 данных XML. Поддержание множества копий этих данных XML может привести к проблемам, включающим в себя то, что копии могут стать несинхронными (например, «название» в панели свойств не согласовано с «названием», отображаемым в строке документа). Для преодоления этой проблемы отдельная «главная» копия каждой части данных XML поддерживается в сессии. Эта главная копия затем используется множеством потребителей данных в течение сессии. Если сессия заканчивается, то другие копии данных могут быть обновлены для отражения текущего состояния хранилища данных XML. Согласно одному варианту осуществления хранилище 302 данных конфигурируется, чтобы выполнять слияние одних и тех же элементов из различных хранилищ данных и затем сохранять каждую копию обратно в последующий момент времени. Если принимается запрос на общий элемент данных, то хранилище 302 данных компонует такие два объекта хранилищ данных в один родительский узел; создает объединенный XSD, который импортирует схемы, которые ассоциированы с каждым элементом данных; и доставляет интерфейс для этого объекта хранилища потребителю данных.

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

Каждый потребитель данных (внутренний 314/внешний 318) может также отклонить недействительные изменения. Например, потребитель данных может включить свой собственный уровень подтверждения действительности. Если потребителем данных запрашивается изменение, которое является недействительным, то это изменение может быть отклонено его существующим уровнем подтверждения действительности, и выполнен возврат назад из его собственного хранилища данных, без уведомления хранилища XML данных. Если это изменение инициировано из хранилища XML данных, то потребитель данных возвращает отклонение события, выданное хранилищем данных, и хранилище данных инициирует отмену для перехода в свое «последнее хорошее» состояние.

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

Для того чтобы поддерживать привязку данных, потребитель данных внутреннего приложения, такой как внутренний потребитель 1 314 данных, обрабатывает взаимодействие между действиями в хранилище XML данных и внешним представлением 315 документа. Если пользователь редактирует поле связывания данных, то это изменение влияет на контент документа (таким образом, добавляя запись в стек «отмена» приложения), но также влияет на контент XML хранилища данных (таким образом, добавляя запись в стек «отмена» хранилища данных). Для обеспечения того, чтобы внешнее представление и данные оставались синхронными постоянно, стек «отмена» приложения (с которым взаимодействует пользователь) может «скомплектовать» изменения внешнего представления в одну запись «отмена», вместе с соответствующей ссылкой «отмена» хранилища XML данных, обеспечивая то, что отмена верхнего объекта в каждом стеке поддерживает приложение и хранилище данных в идентичном состоянии.

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

Если используется глобальный стек отмены, то потребитель данных проходит через запросы отмены непосредственно в главное приложение, которое затем берет последний объект из своего стека отмены (отмена будет той же самой, независимо от того, где было выделение в кадре приложения). Это означает, что все изменения в хранилище XML данных направляются в стек отмены хоста с некоторой обобщенной записью (например, «редактирование свойства отмены»). Например, если пользователь печатает в поле <company/> «Microsoft Corp.» в приложении текстовой обработки, то эта операция вызывает то, что стек отмены хранилища данных включает это действие. Затем, если пользователь хочет ввести «отмена» в приложении текстовой обработки, чтобы удалить этот текст, то приложение текстовой обработки отменяет последнюю операцию над своим стеком отмены (и уведомляет хранилище данных о том, чтобы удалить последнюю операцию в его стеке отмены), что приведет в результате к тому, что другой клиент сделает это действие. И наоборот, если пользователь затем напечатал некоторый несвязанный текст в приложении текстовой обработки и нажал «отмена» на панели, то другой клиент пропустил бы этот запрос в хост, что удалило бы последнее действие из его стека отмены (в этом случае, редактирование внешнего представления документа):

Если потребитель данных отклоняет изменение, посланное хранилищем XML данных, то данные XML могут оборваться на «плохом» состоянии бизнес-логики. Например, предположим, что имеется бизнес-логика, которая выполняет проверки по отчету о затратах. Логика включает проверку, превышает ли элемент строки $100; и если так, то потребитель данных отклоняет обновление поля <lineItemAmount/> («сумма элемента строки»). Если нет, то потребитель данных обновляет итог с новой суммой элемента строки. Если итог превышает $500, то потребитель данных отклоняет обновление поля <reportTotal/> («итог отчета»). Теперь, используя вышеприведенную логику, предположим, что пользователь вводит строку счета $50, которая приводит к превышению итогом суммы $500, тогда первая логическая проверка проходит, но вторая логическая проверка отклоняет обновление итога. Это означает, что если только последнее изменение было отменено, то будет иметься счет, где сумма элементов строк не согласуется с итогом. В результате, согласно одному варианту осуществления, все побочные эффекты исходного изменения отменяются.

Хранилище 302 данных действует как механизм транзакций, который позволяет комплектование этих транзакций вместе для целей отмены. Согласно этому варианту осуществления используются три различные альтернативы для обработки «отклонений». Во-первых, хранилище данных может выдать изменения отмены, чтобы возвратиться в действительное состояние (также называемое «откатом»). Во-вторых, отмена (undo) и аннулирование (cancel) неравноправны, и, в-третьих, никакой клиент не имеет возможности аннулирования.

Первая альтернатива состоит в том, что хранилище XML данных выдает изменения отмены, чтобы вернуться в действительное состояние. Это, по существу, отменяет все операции назад к изменению, которое запустило ошибку бизнес-логики. В этой альтернативе хранилище XML данных могло бы выдать запросы изменения с флагом «undo» (отмена), установленным на TRUE (истинно), и потребители данных выполняли бы эти изменения сами; и хранилище XML данных могло бы выдать запросы изменения со своим установленным флагом «undo». Ниже приведен пример.

По существу потребитель данных принимает два обращения к хранилищу XML данных (запросы на отмену изменений В и С при активизации родительского изменения А), иначе два администратора объектов документа XML выходят из синхронизма.

Другой альтернативой является поддержание текущего неравноправия между аннулированием и отменой, постольку поскольку «аннулирование» потребителем данных текущего изменения может оставить решение в недействительном состоянии бизнес-логики. В этом случае хранилище XML данных выполняет откат только для изменения, которое было отменено/аннулировано, отменяя такое изменение, но затем должно остановиться, чтобы не отменять каких-либо других изменений, которые находятся в стеке отмены хранилища.

Потребители данных могут также поддерживать свои собственные уникальные стеки отмены. Приложения, однако, должны быть «интеллектуальными» в отношении того, чтобы не добавлять дополнительные действия к своим стекам отмены, если самое верхнее действие в их стеке согласуется с запрашиваемой операцией от другой стороны границы синхронизации реального времени. Например, если пользователь печатает в поле <company/> «Microsoft Corp.» в приложении текстовой обработки, то эта операция будет «синхронизирована в реальном времени» и приводит в результате к действию отмены, появляющемуся в каждом стеке отмены зарегистрированного потребителя данных. Затем, если пользователь ввел бы операцию «отмена» в приложении текстовой обработки, чтобы удалить текст, который был только что введен, то приложение текстовой обработки отменило бы последнюю операцию в своем стеке отмены (и сообщило хранилищу данных, чтобы отменить последнюю операцию в его стеке), но в этом случае потребитель данных увидел бы этот запрос и удалил бы последнюю операцию своего стека отмены (включая какие-либо побочные эффекты), поскольку стек отмены хранилища должен обязательно согласовываться с хранилищем данных. Если пользователь затем ввел бы операцию «отмена» у потребителя данных, то потребитель данных удалил бы последнее действие из своего стека отмены, и приложение текстовой обработки, после получения действия отмены из хранилища данных, уведомило бы, что оно согласует последнее действие в своем стеке, и также удалило его. Напротив, если пользователь затем напечатал некоторый не связанный текст в приложении текстовой обработки (добавляя записи отмены в приложение текстовой обработки), прежде чем ввести операцию «отмена» у потребителя данных, клиент удалил бы последнее действие из своего стека отмены, и хранилище сделало бы то же самое, однако приложение текстовой обработки добавляет еще одно действие (поскольку последнее действие над стеком отмены не является последним изменением XML). Однако приложение текстовой обработки сохранило бы это изменение вместе с тем фактом, что хранилище должно выполнить возврат действия, чтобы возвратиться в свое исходное состояние.

Другая альтернатива предусматривает то, что потребители данных ставят в известность друг друга. Управление операцией «отмена» могло бы проходить между потребителями данных. Например, если пользователь редактирует поле <company/> в одном приложении, которое затем транслируется к другому потребителю данных, то стек отмены должен выглядеть следующим образом.

Хранилище	Приложение	Потребитель 1 данных
Маркер (проход к потребителю 1 данных)	Компания-> «Microsoft Corp.»+сохранить отмену	Компания-> «Microsoft Corp.»

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

Хранилище	Приложение	Потребитель 1 данных
Маркер (проход к процессу 1)	Компания-> «Microsoft Corp.»+сохранить отмену	Компания-> «Microsoft Corp.»
Дата->20 января 2005	Дата->29 января 2005 +сохранить отмену	Маркер (проход к хосту)

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

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

Согласно окну 400 документ 415 открыт для редактирования, и показана панель свойств. Заголовок показан как в панели свойств (405), так и в документе (410). Предположим, что заголовок в окне 400 изменился с Data Binding - Live Sync Integration (Связывание данных - интеграция синхронизации в реальном времени) на Foo Bar Biz, как показано в заголовке 435 и заголовке 440 внутри окна 425. Как только заголовок обновляется в заголовке 435 панели свойств, изменение посылается в приложение текстовой обработки, так что оно может принять или отклонить изменение. В этом примере приложение приняло изменение заголовка, которое было сделано с использованием приложения панели свойств, и заголовок 440 внутри документа обновляется.

На фиг.5-8 показаны процессы для синхронизации в реальном времени данных XML между потребителями данных.

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

На фиг.5 иллюстрируется взаимодействие между двумя клиентами и хранилищем данных XML.

Хранилище 520 данных принимает пользовательскую правку для узла А с использованием приложения 510. Потребитель 1 530 данных принимает уведомление об изменении для узла А от хранилища 520 данных. В результате изменения узла А потребитель 1 данных запрашивает изменение побочного эффекта для узла В. Хранилище 520 данных помещает в очередь изменение В побочного эффекта для последующего исполнения. После того как все изменения побочных эффектов помещены в очередь от потребителя 1 данных, хранилище 520 данных уведомляет потребителя 2 (540) данных об изменении узла А. Потребитель 2 данных запрашивает изменение побочного эффекта для узла С. В ответ хранилище 520 данных помещает в очередь изменение С для последующего исполнения. В этот момент обработка, относящаяся к узлу А, завершена, но все еще ожидают изменения побочных эффектов для узла В и узла С. Когда потребитель 1 данных запрашивает изменение для узла В, хранилище данных посылает уведомление о предлагаемом изменении В потребителю 2 данных. Потребитель 2 данных не делает никаких изменений в ответ и принимает изменение. Аналогичным образом, потребитель 2 данных запросил изменение для узла С, так что хранилище данных посылает уведомление об изменении узла С потребителю 1 данных. Потребитель 1 данных принимает изменение. В этом примере все изменения были приняты всеми из заинтересованных потребителей данных. Поэтому хранилище данных помещает изменения в хранилище данных. Короче, хранилище данных разрешает каждому потребителю данных выполнить любые изменения в ответ на изменение, хранилище данных исполняет и сообщает об этих изменениях в порядке, в котором они принимаются, при этом разрешая уведомление о них в последовательности.

Фиг.6 показывает взаимодействие между двумя внешними потребителями данных и изменением в хранилище данных XML.

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

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

Когда потребитель 1 (630) данных запрашивает изменение для узла А, уведомление посылается к потребителю 2 (640) данных после того, как хранилище 620 данных XML принимает запрос на изменение для узла А. В ответ потребитель 2 данных запрашивает изменение побочного эффекта для узла С, которое помещается в очередь хранилищем данных для более позднего исполнения. Потребитель 1 данных затем запрашивает изменение для узла В, которое помещается в очередь, поскольку изменение для узла А еще не завершено. Потребитель 2 данных принимает изменение для узла А, и в ответ хранилище данных исполняет помещенное в очередь изменение побочного эффекта для узла С. Потребитель 1 данных принимает уведомление об изменении узла С и может ответить на это изменение. В этом примере потребитель 1 данных принимает изменение. Хранилище данных затем исполняет помещенное в очередь изменение побочного эффекта для узла В, которое было запрошено потребителем 1 данных. Потребитель 2 данных принимает уведомление об изменении узла В от хранилища данных, на которое он может ответить. Потребитель 2 данных принимает изменение, и изменения осуществляются в хранилище данных.

В этом случае потребитель 2 данных отвечает сначала на изменение для А, так что следующие две строки кода запускают два уникальных изменения:

…

Doc.CustomXMLParts(1).SelectSingleNode().AddNode(«foo»,«bar»)

Doc.CustomXMLParts(1).SelectSingleNode().AddNode(«foo2»,«bar»)

…

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

На фиг.7 показан процесс, затрагивающий множество изменений побочных эффектов. Последующий пример иллюстрирует следующие изменения. Предположим, что потребитель 1 (730) данных, когда он получает уведомление, что узел А изменился, хочет выполнить изменения побочных эффектов для узлов В и С. Потребитель 2 (740) данных в ответ на уведомление об изменении для узла В хочет выполнить изменения побочных эффектов для узлов D, E и F.

Ссылаясь на фиг.7, можно видеть, что потребитель 1 данных обуславливает все свои изменения побочных эффектов как результат уведомления об изменении узла А, прежде чем побочные эффекты, относящиеся к изменению узла В, будут выполнены. Поэтому изменения для узла С происходят перед изменениями для узлов D, E и F.

Фиг.8 иллюстрирует процесс, показывающий, что побочные эффекты запрашивающей стороны исполняются последними. Можно также видеть в этом случае, что побочные эффекты, генерируемые потребителем 1 данных, будут происходить после того, как все другие клиенты имели шанс увидеть изменения и генерировать свои собственные побочные эффекты. Это является обязательным побочным эффектом того факта, что хранилище данных XML информирует каждого клиента об изменении (чтобы гарантировать, что клиент имеет шанс принять/отклонить это изменение), прежде чем сможет возвратить условие успеха запрашивающей стороне, и позволяет запрашивающей стороне предоставить событие, которым осуществляются побочные эффекты. Является предсказуемым, что потребитель данных, который запросил изменение, должен быть последним, для того чтобы воспринять, было ли изменение принято или отклонено всеми клиентами хранилища данных XML. А также это помогает гарантировать, что если два изменения являются конфликтующими и не структурными, то изменение запрашивающей стороны пользуется приоритетом, что, в принципе, является желательным результатом.

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

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

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

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

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

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

6. Машиночитаемый носитель по п.3, дополнительно содержащий поддержание списка отмены, который может быть использован для возврата хранилища данных назад в состояние перед моментом временем, когда было инициировано изменение.

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

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

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

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

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

12. Реализуемый компьютером способ по п.9, дополнительно содержащий поддержание списка отмены, который используется для возврата хранилища данных назад в последнее известное хорошее состояние.

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

14. Система по п.13, дополнительно содержащая структурирование структурированных элементов данных в хранилище данных в соответствии с расширяемым языком разметки (XML).

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

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

17. Система по п.15, в которой хранилище данных дополнительно конфигурировано для:
приема изменения данных XML-разметки, примененных к структурированному элементу данных;
считывания файла схемы XML, ассоциированного со структурированным элементом данных, на который направлено изменение данных XML-разметки;
определения, является ли изменение данных XML-разметки действительным в соответствии со считанным файлом схемы XML; и
неразрешения изменения данных XML-разметки, если изменение данных XML-разметки не является действительным, в соответствии со считанным файлом схемы XML; и
осуществления изменения, если изменение в данных XML-разметки является действительным в соответствии со считанным файлом схемы XML.

18. Система по п.15, в которой хранилище данных содержит множество хранилищ данных XML, каждое из которых содержит хранилище отмены и хранилище изменения.

19. Система по п.18, в которой каждое хранилище отмены конфигурировано для информационного обмена с другими хранилищами отмены.