BRPI0615679B1 - sincronização em tempo real de dados de xml entre aplicações - Google Patents

Abstract

sincronização em tempo real de dados de xml entre aplicações uma ou mais memórias de dados são mantidas separa- damente de um armazenamento de apresentação primário dentro de um documento para armazenar, relacionar e para permitir o uso de dados arbitrários que são associados com um documento gerado pelo computador entre múltiplos consumidores de dados. a memória de dados expõe as interfaces de programação da aplicação (api) para os vários pedaços de dados na memória de dados para permitir que consumidores de dados diferentes acessem e operem em um ou mais dos pedaços de dados em tempo real. múltiplos consumidores de dados podem acessar e editar o mesmo pedaço de dados simultaneamente e quaisquer mudanças conflitantes em um dado pedaço de dados são resolvidas. cada consumidor de dados pode aceitar ou rejeitar a mudança, bem como fazer mudanças adicionais de efeito colateral como um resultado da mudança original. dessa maneira, os dados podem ser sincronizados em tempo real através dos consumidores de dados.

Description

(54) Título: SINCRONIZAÇÃO EM TEMPO REAL DE DADOS DE XML ENTRE APLICAÇÕES (51) Int.CI.: G06F 17/00 (30) Prioridade Unionista: 09/09/2005 US 60/715,986, 13/01/2006 US 11/332,468 (73) Titular(es): MICROSOFT TECHNOLOGY LICENSING, LLC (72) Inventor(es): ALI TALEGHANI; BRIAN M. JONES; MARCIN SAWICKI; ROBERT A. LITTLE; SHIRAZ CUPALA; DRAGOS BARAC (85) Data do Início da Fase Nacional: 05/03/2008

SINCRONIZAÇÃO EM TEMPO REAL DE DADOS DE XML ENTRE APLICAÇÕES

ANTECEDENTES

Os usuários de computador cresceram acostumados com aplicações de software convenientes para os usuários que os ajuda a escrever, calcular, organizar, preparar apresentações, enviar e receber correio eletrônico, fazer música e semelhantes. Por exemplo, aplicações de processamento de texto permitem que os usuários preparem uma variedade de documentos úteis. Aplicações de planilha permitem que os usuários insiram, manipulem e organizem dados. Aplicações de apresentação de slide permitem que os usuários criem uma variedade de apresentações de slide contendo texto, imagens, dados ou outros objetos úteis.

Os documentos criados por tais aplicações (por exemplo, documentos de processamento de texto, planilhas, documentos de apresentação de slide), entretanto, têm uma facilidade limitada para armazenar/transportar os conteúdos de metadados arbitrários requeridos pelo contexto dos documentos. Por exemplo, uma solução construída em cima de um documento de processamento de texto pode requerer o armazenamento de dados de fluxo de trabalho que descrevem vários estados do documento, por exemplo, estados de aprovação prévios do fluxo de trabalho (datas, horas, nomes), estados de aprovação atuais, estados de fluxo de trabalho futuros antes da conclusão, nome e endereço do escritório do autor do documento, mudanças no documento e semelhantes. As opções para armazenar essa informação são primariamente limitadas ac uso

—_ d cí Ç 3.0 td i 11U U Γ C Ü Σ □ Ç α ü il jU '61^ ( viu t ; UÇÍõOhsii^üd^ ΰ X _ i tentes que têm limitações. Por exemplo, os dados hierárquicos podem nào ser armazenados, o comprimento do caractere é limitado e semelhantes. As propriedades para tais métodos são armazenadas em uma única memória, por exemplo, uma memória de propriedades de OLE, o que significa que as propriedades têm uma possibilidade de conflito. Além disso, tais propriedades armazenadas não têm validação de dados. É difí10 cil para os usuários de tais aplicações e documentos relacionados armazenar dados arbitrários com documentos, que é uma necessidade comum de muitos usuários.

SUMÁRIO

Esse sumário é provido para apresentar uma seleção de conceitos em uma forma simplificada que são também descritos abaixo na descrição detalhada. Esse sumário não é planejado para identificar aspectos chaves ou aspectos essenciais da matéria exposta reivindicada, nem ele é planejado para ser usado como uma ajuda na determinação do escopo da matéria exposta reivindicada.

Uma ou mais memórias de dados são mantidas separadamente de um armazenamento de apresentação primário dentro de um documento para armazenar, relacionar e para permitir o uso de dados arbitrários que são associados com um documento gerado pelo computador entre múltiplos consumidores de dados. Os dados para estruturar a informação associada com um documento, tal como metadados do documento, são mantidos em uma memória de dados onde as relações entre pedaços diferen-

.óL-ulCõ de pl·'QCj Γ díTld Çci ü dd âpi LCuyaC (A?ÍS; pd±73 OS VuílCS pedaços de dados na memória de dados para permitir que consumidores de dados diferentes acessem e operem em um ou mais des pedaços de dados em tempo real. Múltiplos consumidores de dados podem; acessar e editar o mesmo pedaço de dados simultaneamente e quaisquer mudanças conflitantes para um dado pedaço de dados são resolvidas. Cada consumidor de dados pode aceitar ou rejeitar a mudança, bem como fazer mudanças adicionais de efeito colateral como um resultado da mudança original. Dessa maneira, os dados podem ser sincronizados em tempo real através dos consumidores de dados.

Os pedaços de dados podem ser estruturados de acordo com uma linguagem de marcação tal como a linguagem de marcação extensível (XML). Esquemas da XML podem ser associados com cada pedaço de dados e a memória de dados pode automaticamente validar a estrutura da XML dos dados com base em um esquema da XML associado com um dado pedaço de dados. Isso ajuda a impedir que mudanças inválidas tenham permissão para entrar no sistema.

BREVE DESCRIÇÃO DOS DESENHOS

A figura 1 ilustra uma arquitetura de computação exemplar para um computador,

A figura 2 é um diagrama de blocos ilustrando uma relação entre uma ou mais aplicações de cliente e uma ou mais memória(s) de dados e os conteúdos da(s) memória(s) de dados

A figura 3 ilustra um diagrama de sistema mostran4

do a interação entre os consumidores de dados interno e externo com as memórias de dados da XML,

A figura 4 ilustra um exemplo da sincronização ativa,

A figura 5 ilustra a interação entre dois clientes e uma memória de dados da XML,

A figura 6 mostra a interação entre dois consumidores de dados externos e uma mudança na memória de dados da

XML,

A figura 7 mostra um processo envolvendo múltiplas mudanças de efeito colateral e

A figura 8 ilustra um processo mostrando que os efeitos colaterais do chamador são executados por último, de acordo com aspectos da presente invenção.

DESCRIÇÃO DETALHADA

Com referência agora os desenhos, nos quais numerais semelhantes representam elementos semelhantes, vários aspectos da presente invenção serão descritos. Em particular, a figura 1 e a discussão correspondente são planejados para prover uma breve descrição geral de um ambiente de computação adequado no qual modalidades da invenção podem ser implementadas.

De forma gerai, módulos do programa incluem rotinas, programas, componentes, estruturas de dados e outros tipos de estruturas que executam tarefas particulares ou implementam tipos de dados abstratos particulares. Outras configurações do sistema de computador podem também ser usadas, incluindo dispositivos de mão, sistemas de muitiprocessador,

-L_ L—' J— õ J J . J d '\_A ·. s__J 1 2 ·—X J. L L _L —Λ -O 1 <_> ϊ . I L_, CJ iÇj AJ --- 2 l L x ·. L —L· x — J_ '^2 2 _L— '·--' —-· -—- t-O· d *_^l J_ ·—' '—K ρ X O C2 ama Vθ r _f .'/[ i .'/ 1 ·.' OlCp . ...,- QO Γ6 £ , k.:ΟΠ, O U L U'—. .--1.- S grande p Ο r - i e semelhantes. Ambientes de computação distribuídos podem também ser usados onde as tarefas são executadas por dispo5 sitivos de processamento remoto que são ligados através de uma rede de comunicações. Em um. ambiente de computação distribuído, módulos de programa podem ficar localizados em ambos os dispositivos de armazenamento de memória locais e remotos ,

Por todo o relatório descritivo e reivindicações, os seguintes termos adotam os significados associados aqui, a menos que o contexto do termo dite de outra forma.

O termo apresentação se refere à porção visível do documento tais como o texto e o leiaute que apareceríam se o documento fosse impresso.

O termo marca se refere aos caracteres inseridos em um documento que delineiam os elementos dentro de um documento da XML. Cada elemento não pode ter mais do que duas marcas: a marca de início e a marca de fim. É possível ter um elemento vazio (sem conteúdo) em cujo caso uma marca é permitida.

Os termos linguagem de marcação ou ML se referem a uma linguagem para códigos especiais dentro de um documento que especificam como as partes do documento devem ser interpretadas por uma aplicação. Em um arquivo de processador de texto, a linguagem de marcação especifica como o texto deve ser formatado ou disposto.

O termo elemento se refere à unidade básica de

um documento da XML. O elemento pode conter atributos, outros elementos, texro e outras regiões de conreúdo para um documento da XML.

conteúdo da XML entre as marcas é considerado o secundário do elemento (ou descendentes). Portanto, outros elementos incorporados no conteúdo do elemento são chamados elementos secundários ou nós secundários ou o elemento.

texto incorporado diretamente no conteúdo do elemento é considerado os nós do texto secundário do elemento. Jun10 tos, os elementos secundários e o texto dentro de um elemento constituem o conteúdo desse elemento.

O termo atributo se refere a uma propriedade adicional estabelecida para um valor particular e associada com um elemento. Os elementos podem ter um número arbitrário de ajustes de atributo associados com eles, incluindo nenhum. Os atributos são usados para associar a informação adicional com um elemento que não conterá elementos adicionais ou será tratado como um nó do texto.

termo XPath é um operador que usa uma expres20 são padrão para identificar nós em um documento da XML. Um padrão de XPath é uma lista separada por traços oblíquos dos nomes do elemento secundário que descrevem uma trajetória através do documento da XML. 0 padrão seleciona elementos que igualam a trajetória.

O termo mudança de efeito colateral se refere a uma mudança que é feita em resposta a uma outra mudança.

O termo documento pode consistir da XML arbitrária que descreve as propriedades que são definidas no tipo

oe ^cnteudo õssuCiàQL·, oem como dS outras .linguagens cie mar cação que podem ser asadas para descrever o conteúdo de superfície real· do· documento:

O termo memória de dados da XML e/ou memória de dados se refere a um recipiente dentro de um documento, tal como um documento de processador de texto, um documenpo de planilha, um documento de apresentação de slide, etc., que provê acesso para o armazenamento e modificação dos dados (no formato da XML, por exemplo) armazenados no documento enquanto o arquivo está aberto. Definição adicional da memória de dados da XML é provida abaixo com relação à figura 2.

Com referência à figura 1, um sistema exemplar para implementar a invenção inclui um dispositivo de computação, tal como dispositivo de computação 100. Em uma configuração muito básica, o dispositivo de computação 100 tipicamente inclui pelo menos uma unidade de processamento 102 e memória do sistema 104. Dependendo da configuração exata e do tipo do dispositivo de computação, a memória do sistema 104 pode ser volátil (tal como RAM), não volátil (tal como ROM, memória flash, etc.) ou alguma combinação das duas. A memória do sistema 104 tipicamente incluí um sistema operacional 105, uma ou mais aplicações 106 e pode incluir dados do programa 107. Em uma modalidade, a aplicação 106 pode incluir uma aplicação de processador de texto 120. Essa configuração básica é ilustrada na figura 1 por esses componentes dentro da linha tracejada 108.

dispositivo de computação 100 pode ter aspectos ou funcionalidade adicional. Por exemplo, o dispositivo de // / h í ¹ computação iüO pode também incluir dispositivos de armazenamento de dados adicionais (removíveis e/ou não removíveis) tais como, por exemplo, discos magnéticos, discos óticos ou fita. Tal armazenamento adicional é ilustrado na figura 1 pelo armazenamento removível 109 e armazenamento não removível 110. Meios de armazenamento no computador podem incluir meios voláteis e não voláteis, removíveis e não removíveis implementados em qualquer método ou tecnologia para armazenamento de informação, tais como instruções legíveis por computador, estruturas de dados, módulos do programa ou outros dados. A memória do sistema 104, armazenamento removível 109 e armazenamento não removível 110 são todos exemplos de meios de armazenamento no computador. Meios de armazenamento no computador incluem, mas não são limitados a, RAM,

ROM, EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento ótico, cassetes magnéticos, fita magnética, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético ou qualquer outro meio que possa ser usado para armazenar a informação desejada e que possa ser acessado pelo dispositivo de computação 100. Quaisquer tais meios de armazenamento no computador podem ser parte do dispositivo 100. O dispositivo de computação 100 pode também ter dispositivo (s) de entrada 112 tais como teclado, mouse, caneta, dispositivo de entrada de voz, dispositivo de entrada por toque, etc. Dispositivo (s) de saída 114 tais como um monitor, alto-falantes, impressora, etc., podem também ser incluídos. Esses dispositivos são bem conhecidos na técnica e

não precisam ser discutidos em maiores detalhes aqui .

dispositivo de computação 100 pode também conter conexões de comunicação 116 que permitem, que o dispositivo se comunique com outros dispositivos de computação 118, tal como através de uma rede. A cor.exão de comunicação 116 é um exemolo dos meios de comunicação. Os meios de comunicação podem ser tipicamente personificados por instruções legíveis por computador, estruturas de dados, módulos do programa ou outros dados em um sinal de dados modulado, tal como uma on10 da portadora ou outro mecanismo de transporte e inclui quaisquer meios de entrega de informação. O termo sinal de dados modulado significa um sinal que tem uma ou mais de suas características ajustadas ou alteradas em uma tal maneira de modo a codificar a informação no sinal. Por meio de exemplo, e não limitação, meios de comunicação incluem meios ligados por fiação tal como uma rede ligada por fiação ou conexão ligada por fiação direta e meios sem fio tais como meios sem fio acústicos, de RF, de infravermelho e outros. O termo meios legíveis por computador como usado aqui inclui ambos os meios de armazenamento e meios de comunicação.

Uma série de módulos do programa e arquivos de dados pode ser armazenada na memória do sistema 104 do dispositivo de computação 100, incluindo um sistema operacional 105 adequado para controlar a operação de um computador pes25 soai em rede, tal como os sistemas operacionais WINDOWS da MICROSOFT Corporation de Redmond, Washington. A memória do sistema 104 pode também armazenar um ou mais módulos do programa, tal como a aplicação do processador de texto 120, e

outros descritos abaixo. A aplicação do processador de rpxto 120 é operativa para prover funcionalidade para criar, editar e processar documentos eletrônicos.

De acordo com uma modalidade da invenção, a apli5 cação do processador de texto 120 compreende o programa WORD da MICROSOFT CORPORATION. Deve ser verificado, entretanto, que programas de aplicação de processador de texto de outros fabricantes podem ser utilizados. A ilustração de uma aplicação de processamento de texto é com finalidades de exemplo somente e não está limitando outros tipos de aplicações que podem produzir e operar nos documentos. Por exemplo, outros programas de aplicação 106 que são capazes de processar várias formas de conteúdo (por exemplo, texto, imagens, desenhos, etc.), tais como programas de aplicação de planilha, programas de aplicação de base de dados, programas de aplicação de apresentação de slide, programas de aplicação auxiliados por computador ou de desenho, etc., são igualmente aplicáveis. Um programa de aplicação exemplar 106 que produz e opera em uma variedade de tipos diferentes de documentos inclui o OFFICE da MICROSOFT Corporation.

Modalidades podem ser implementadas como um processo de computador, um sistema de computação ou como um artigo de fabricação tal como um produto de programa de computador ou meios legíveis por computador. 0 produto de progra25 ma de computador pode ser meios de armazenamento no computador legíveis por um sistema de computador e codificação de um programa de computador das instruções para executar um processo no computador. 0 produto do programa de computador

X?

pode também ser um sinal orooagado em uma pnrtaHnra 1 agí v<= 1 por um sistema de computação e codificação de um programa de computador das instruções para executar um processo do computador .

A figura 2 é um diagrama de blocos ilustrando uma

mais memórias de dados e os conteúdos da(s) memória(s) de dados. Geralmente descrito, uma ou mais memórias de dados são mantidas separadamente de um armazenamento de apresenta10 ção primário dentro de um documento para armazenar, relacionar e para permitir o uso de dados arbitrários através de consumidores de dados que são associados com um documento gerado pelo computador. Dados para estruturar a informação associada com um documento, tal como metadados do documento, são mantidos em uma memória de dados onde as relações entre pedaços de dados diferentes são mantidas. A memória de dados expõe as interfaces de programação de aplicação (APIs) aos vários pedaços de dados na memória de dados para permitir que aplicações diferentes acessem e operem em um ou mais dos pedaços de dados. Como usado aqui, os termos consumidores de dados, aplicações e processos podem ser usados de maneira permutável a menos que o contexto claramente dite de outra forma.

Os pedaços de dados podem ser estruturados de a25 cordo com uma linguagem de marcação tal como a linguagem de marcação extensível (XML). Esquemas da XML podem ser associados com cada pedaço dos dados e a memória de dados pode validar a estrutura da XML aplicada nos dados com base em um

esctuema da XML associado com um dado oedaco dos dados para garantir a validade de cada solicitação. As memórias de dados podem conter qualquer número de itens de dados arbitrários, por exemplo, metadados, estruturados de acordo com a linguagem de marcação extensível (XML). Dessa maneira, prc-

arbitrários como XML com um dado documento e ter essa informação processada por uma dada solução tendo acesso aos dados com a ocorrência de um evento tal como quando os dados são removidos ou carregados na memória de dados e/ou quando o documento é aberto/editado/salvo por um usuário.

O acesso programático é também provido para os dados na sua forma de XML enquanto o documento está sendo editado. De acordo com uma modalidade, um mecanismo padrão é provido que é familiar para desenvolvedores de solução via o qual os dados podem ser acessados e modificados de maneira programática enquanto o documento está aberto. Esse acesso programático é projetado para imitar APIs de XML padrões. O acesso programático aos dados é provido via interfaces de programação da aplicação para uma ou mais aplicações do cliente de edição (por exemplo, aplicações de edição ou criação de documento e/ou soluções de complemento da aplicação de terceiros e semelhantes). Dessa maneira, múltiplas aplicações de cliente podem acessar e editar o mesmo pedaço dos dados de documento e quaisquer mudanças conflitantes para um dado pedaço de dados são resolvidas. Consumidores de dados podem fazer mudanças de efeitos colaterais em resposta a qualquer dada mudança. Por exemplo, em resposta ao estabele13

;m consumidor de dados pode alterar um simboio de estoque para 'ΜΞΕΤ. Alé' iisso, mudanças em dados e quaisquer ereitcs colaterais associados podem ser agrupadas pela memória de dados, de modo que a anulação de uma ou mais mudanças inverte todas as mudanças relacionadas. Isso auxilia na remoção do fardo de desenvolvimento do próprio consumidor de dados para garantir que ele inverteu todas as mudanças quando o usuário inicia uma anulação da mudança original a partir da superfície do documento, por exemplo, pelo aperto de comando desfazer.

Esquemas de XML padrões (XSDs) podem também ser usados para definir os conteúdos de qualquer um dos pedaços dos dados de XML personalizados associados com metadados de documento a fim de garantir que os dados de XML aplicados nos dados do documento sejam válidos. Esses esquemas podem ser anexados a qualquer instância dos dados da XML armazenados no documento e a memória de dados pode ser configurada para proibir qualquer mudança nos dados da XML que resultaria na estrutura da XML (isto é, as marcas da XML em oposição aos seus conteúdos) desses dados se tornando inválida. Isso ajuda a garantir que o desenvolvedor da solução possa anexar um pedaço específico dos metadados da XML em um documento e garantir que os dados da XML continuarão a ser estruturalmente corretos de acordo com o esquema associado, a despeito de quais consumidores de dados (por exemplo, complementos) são usados para modificar esses dados. O esquema pode ser armazenado em um meio legível por computador, tal /

como em um arquivo ou em uma unidade rígida.

Com referência agora à figura 2, os dados do documento 220 incluem dados de estrutura da XML e dados de documento associados representando a superfície ou visão do ní5 vel de apresentação de um. documento. Por exemplo, os dados do documento 220 podem incluir a estrutura da XML (por exemplo, marcas de cabeçalho, marcas de corpo, marcas de conclusão) e dados de visualização de superfície associados (por exemplo, palavras, frases, parágrafos) de um documento de processamento de texto, documento de planilha, documento de apresentação de slide e semelhantes.

A memória de dados 208 é um repositório dos dados do documento para armazenar um ou mais pedaços dos dados estruturados associados com um ou mais tipos de dados associa15 dos com um dado documento. Embora somente uma memória de dados seja ilustrada, mais do que uma memória de dados pode ser utilizada. Os metadadosl 225 (item de dados estruturados) podem incluir dados de estrutura da XML e dados associados para um primeiro pedaço dos metadados associados com o documento. Por exemplo, os metadadosl 225 podem incluir dados de estrutura da XML (por exemplo, marcas de data, marcas de nome, etc.) listando o autor do documento, data da criação do documento, data da última mudança/salvamento do documento e semelhantes. Os metadados2 230 (item dos dados es25 truturados) podem incluir dados da estrutura da XML (marcas) e metadados associados representando um segundo pedaço dos metadados associados com o documento. Os metadadosl e os metadadosl são para finalidades de exemplo e não estão limí15

tando a varaedade e o número de íídos diferentes de ciados que poaem ser mantidos na memória de dados 208 em associação com um dado documento. Por exemplo, como descrito aqui, dados arbitrários podem ser estruturados e adicionados no do5 cumento por uma ou mais aplicações de software como desejado pelos orovedores de solução ou usuários c-io acesso aos dados do documento.

Um arquivo de esquema 240,245 pode ser opcionalmente anexado a cada pedaço dos dados armazenados na memória de dados 208 para ditar as regras de sintaxe e validação associadas com os dados da linguagem de marcação extensível (XML) aplicados em cada pedaço dos dados 225,230. Arquivos do esquema da XML provêem uma maneira para descrever e validar os dados em um ambiente da XML. Um arquivo de esquema declara quais dados de marcação da XML, incluindo elementos e atributos, são usados para descrever o conteúdo em um documento da XML e o arquivo do esquema define a sintaxe de marcação da XML, incluindo onde cada elemento é permitido, quais tipos de conteúdo são permitidos dentro de um elemento e quais elementos podem aparecer dentro de outros elementos. 0 uso dos arquivos de esquema garante que o documento (ou pedaço individual dos dados) seja estruturado em uma maneira consistente e previsível. Arquivos de esquema 240,245 podem ser criados por um usuário e geralmente suportados por uma linguagem de marcação associada, tal como XML.

Essa esquematização do documento permite que a memória de dados proveja a capacidade para garantir a validade estrutural do documento rejeitando qualquer mudança que

viola um aaáo arquivo de esquema no nível da memória de dados. De acorao com uma modalidade, a memória de dados 208 utiliza um módulo de validação de esquema 260 para validar a estrutura da XML adicionada a ou as mudanças feitas em um dado pedaço dos dados contra um arquivo de esquema associado. Por exemolo, se um criador ou edjt-or do documento faz mudanças estruturais da XML em um dado pedaço dos dados, por exemplo, os metadadosl, onde o editor adiciona ou remove uma dada marca da XML, a memória de dados 208 utilizará o módulo de validação do esquema para verificar as mudanças estruturais da XML contra o arquivo de esquema associado para garantir a validade da mudança. Se a mudança não é válida, um erro pode ser gerado para o editor. Como é entendido, tal controle da estrutura da XML aplicada em um dado pedaço de dados permite a consistência estrutural e a capacidade de predição que são especialmente importantes para permitir que aplicações de cliente e terceiros interajam com os dados associados. Qualquer consumidor de dados pode prover um esquema que pode ser usado para validar os dados.

A memória de dados 208 provê uma ou mais interfaces de programação de aplicação (API) 270 que podem ser acessadas por aplicações do cliente 205 (por exemplo, aplicações de processamento de texto, aplicações de planilha, aplicações de apresentação de slide, etc.), bem como, aplicações de terceiros 210,215 e via os modelos de objeto (OM) das aplicações respectivas 205, 210, 215. Essas APIs permitem que as aplicações do cliente e aplicações de terceiros carreguem qualquer arquivo de XML existente na memória de

dados ae um dado aocumento 203, assim garantindo que esses dados sejam agora parte do documento e percorrerão dentro desse documento por sua duração de vida (por exemplo, através de abrir/editar/salvar/renomear/etc.) ou até que os da5 dos sejam deletadcs da memória de dados. De acordo ccm uma modalidade, os dados na memória de dados ficam disponíveis no seu formato de XML mesmo quando uma aplicação fonte para um dado pedaço de dados 225, 230 é fechada ou de alguma forma não está disponível. Isto é, um dado pedaço dos dados

225, 230 pode ser acessado via um conjunto de APLs. Como descrito abaixo, as APIs também permitem que aplicações do cliente e de terceiros façam mudanças nos dados de marcação da XML aplicados nos itens de dados 225, 230.

Depois que os dados da XML 225, 230 são carregados na memória de dados para associação com um documento 220, eles podem ser manipulados como XML padrão usando as interfaces da memória de dados designadas para prover métodos similares para interfaces de edição de XML existentes de modo a alavancar o conhecimento existente dos desenvolvedores do padrão de programação da XML. Isso permite que os usuários executem operações de XML padrões em dados de XML adicionados na memória de dados para um documento, tal como a adição de elementos e atributos, remoção de elementos e atributos, mudança no valor dos elementos/atributos existentes e leitu25 ra dos valores de qualquer parte existente da árvore da XML associada. Usando essas operações padrões da XML, as soluções podem armazenar metadados complexos estruturados com um documento. Por exemplo, uma aplicação de terceiros 215 pode

ser escrita para localizar e extrair nomes de antoi- de do,-i.·mento e datas de criação do documento de um número de documentos pela leitura dos metadadosl 225 adicionados na memória de dados 208 para cada documente. A aplicação de tercei5 res exemplar pode ser uma aplicação programada Dara fazer uma lista de nomes de autor de documenta e datas de criação de documento para todos os documentos criados por uma dada organização. De acordo com modalidades da presente invenção, a aplicação de terceiros pode utilizar a estrutura da XML aplicada nos metadadosl para eficientemente localizar e extrair os dados desejados. Por exemplo, a aplicação de terceiros pode ser escrita para analisar a estrutura da XML do arquivo de metadadosl para localizar marcas da XML, tais como <docauthor> e <doccreationdate> para obter e usar os da15 dos associados com essas marcas. Como deve ser verificado, o precedente é apenas um exemplo das muitas maneiras que uma ou mais aplicações podem interagir com os dados estruturados que são associados com o documento via a memória de dados

208.

Além disso, a memória de dados 208 provê qualquer número de interfaces da API 270 para qualquer pedaço individual de dados da XML 220, 225, 230 (também conhecidos como um item da memória) para possibilitar que múltiplas aplicações 205, 210, 215 funcionem com o mesmo pedaço de dados.

Por exemplo, várias soluções, tal como uma aplicação do cliente (por exemplo, aplicação de processamento de texto) e soluções de aplicação de terceiros (por exemplo, a aplicação de terceiros descrita acima), podem funcionar com o mesmo

conjunto de propriedades de documento (por exemplo, propriedades contidas no arquivo de metadados2 230). Usando a memória de dados 208, cada uma dessas aplicações recebe acesso separado para os dados da XML desejados 230 através de sua própria interface API da memória de dados 270 para permitir qu P C 3. CeU L-. O 2_ _L ^r ' ci omil 1’ · gi θ s—· QTT' C7 3. ÇÍ Ά S ^Ί7ΐ - s ° 1 ¹ Ά .Λ p T -! ,o gerenciador de objeto sem ter que lidar com a complexidade de ter múltiplos consumidores de dados acessando o mesmo pedaço dos dados.

A fim de permitir que essas múltiplas aplicações 205, 210, 215 acessem os mesmos dados, a memória de dados 208 notifica cada uma dessas aplicações quando qualquer parte dos dados da XML é alterada por uma outra aplicação de modo que uma dada aplicação pode responder para essa mudança (tanto internamente ao seu próprio processo quanto externamente por outras mudanças nos mesmos dados). Quando uma aplicação solicita uma mudança para um dado item de dados, essa solicitação é automaticamente enviada para todas as outras aplicações .para permitir que as outras aplicações decidam como ou se responder para a mudança solicitada. De acordo com uma modalidade, isso é realizado permitindo que cada aplicação se inscreva para participar de qualquer parte dos dados da XML nos quais ele tem uma interface de modo que uma dada solução/programa de aplicação somente recebe essas mensagens que são pertinentes para sua própria lógica. Por exemplo, um tipo de aplicação 210 pode desejar se inscrever para participar de todas as mudanças feitas nos dados de uma dada XML de modo a prover capacidades detalhadas de lógica

do negócio para uma solução de terceiros, mas um our.ro tipo de aplicação 215 pode desejar somente participar das mudanças em um ou dois elementos da XML específicos dentro dos mesmos dados porque sua lógica não se preocupa com as mudan5 ças em qualquer outra parte dos dados da XML.

De acordo com essa modalidade, as múltiplas aplicações 205, 210, 215 podem acessar e editar o mesmo pedaço dos dados de documento e quaisquer mudanças conflitantes para um dado pedaço de dados são resolvidas. Por exemplo, e10 feitos colaterais em qualquer dada mudança podem ser feitos quando uma mudança por uma aplicação causa uma mudança de efeito colateral por uma outra aplicação. Por exemplo, uma primeira aplicação 210 pode ser encarregada de extrair nomes de companhia de um ou mais itens de dados 225, 230 associa15 dos com um dado documento para traduzir esses nomes em símbolos de estoque correspondentes, se disponível, para compilar uma lista de símbolos de estoque da companhia relacionados com um dado documento. Se uma segunda aplicação 215 faz com que um dado nome de companhia em um dado pedaço dos me20 tadados seja adicionado ou seja alterado, por exemplo, mudando o nome da companhia de companhia ABC para companhia XYZ, a primeira aplicação pode participar dessa mudança para automaticamente atualizar a sua lista de símbolos de estoque para incluir o símbolo de estoque para a companhia 25 XYZ ao invés da companhia ABC. Além disso, tais mudanças e quaisquer efeitos colaterais associados podem ser agrupados pela memória de dados 208 de modo que a anulação de uma ou mais mudanças reverte todas as mudanças relacionadas.

A figura 3 ilustra um diagrama de sistema mostrando a interação entre os consumidores de dados internos e externos com as memórias de dados da XML. Como ilustrado, o sistema 300 inclui documento 315, uma memória de dados 302, 5 uma camada de apresentação 304, memórias da XML 1-N 306 dentro da memória de dados 202 que incluem, cada uma, uma memória de erro e uma memória de anulação, uma memória de mudança global 308, uma memória de anulação global opcional 310, um agente interno 312 que é acoplado nos consumidores de da10 dos internos 1-N 314, memória externa da XML 320 e um agente externo 316 que é acoplado nos consumidores de dados externos 1-N 318.

Com o uso da memória de dados 302 e a(s) memória (s) de dados da XML 306, os documentos têm a capacidade de conter qualquer número de itens de dados arbitrários (contanto que cada um se conforme com a sintaxe da XML padrão) . Metadados arbitrários podem ser armazenados como XML dentro de um documento e essa informação pode ser automaticamente circulada quando o documento é aberto/editado/salvo pelo usuário.

Como discutido acima, o acesso programático a esses dados é provido via uma API que pode ser utilizada enquanto o documento está sendo editado, provendo um mecanismo padrão familiar para desenvolvedores de solução via o qual essa informação pode ser acessada e modificada de modo programático enquanto o documento está aberto. De acordo com uma modalidade, esse acesso programático é projetado para imitar as interfaces da XML padrões. Com o uso da API, os

dados podem ser adicionados/removidos enquanto a aplicação, tal como uma aplicação de processamento de texto, está funcionando, os dados podem ser preenchidos dentro de um item da memória (uma parte dentro da memória de dados] , os dados podem ser manipulados usando construções da XML padrões, esquemas podem ser associados com quaisquer dados da XML arbitrários na memória de dados, esquemas podem ser adicionados/removídos/alterados uma vez associados com o item da memória de dados e mudanças da XML podem ser transmitidas para quaisquer clientes participantes. Como ilustrado, a API compreende um agente externo 316 que provê uma interface para os consumidores de dados externos 318 e um agente interno 312 que provê uma interface para quaisquer consumidores de dados internos 314 que interagem com a memória de dados 302.

As manipulações na memória de dados 302 podem ocorrer em tempo real. Como discutido acima, as memórias de dados 302 e 306 podem conter um ou mais tipos de dados. Por exemplo, uma companhia podería ter uma memória de dados que eles estão usando para armazenar todos os tipos diferentes de dados que eles desejam armazenar dentro de uma única memória de dados, enquanto uma outra companhia poderia querer armazenar tipos diferentes de dados dos dados através de diferentes memórias de dados.

Um consumidor de dados (interno 314 e/ou externo

318) pode se inscrever para eventos que se relacionam com ações com relação aos dados dentro das memórias de dados.

Por exemplo, um consumidor de dados pode se inscrever para receber um evento quando qualquer tipo de mudança é feita em

uma ou mais das memórias de dados. Um nutro consumidor de dados pode se inscrever para mudanças que aconteceram em um certo elemento ou conjunto de elementos dentro de uma memória de dados. Eventos comuns incluem adicionar um item, rau5 dar um item e deletar um item de uma das memórias de dados.

Quando o evento ocorre, cada consumidor de dados que se inscreveu pode reagir à mudança enquanto o estado das memórias de dados é mantido consistentemente. Muitas vezes, um consumidor de dados não executará quaisquer ações quando uma mu10 dança é feita. Em outras vezes, o consumidor de dados executará algumas ações em resposta ao evento. Por exemplo, um consumidor de dados pode fazer algumas outras mudanças na memória de dados em resposta à mudança tal como, em resposta a uma mudança de título, atualizar cabeçalhos dentro do do15 cumento. O consumidor de dados pode também executar algumas outras operações que não afetam o documento. Por exemplo, se o símbolo registrador do estoque é inserido, o consumidor de dados pode recuperar os dados que são associados com esse símbolo do estoque mesmo embora todos os dados recuperados possam não ser exibidos dentro do documento na camada de apresentação. 0 consumidor de dados pode também rejeitar a mudança usando sua própria lógica de validação. Por exemplo, se o consumidor de dados 1 recebe uma mudança que eles não aceitam, esse consumidor de dados pode retornar um indicador para o agente indicando que a mudança não é aceita. Sempre que uma mudança não é aceita, a mudança é revertida, junto com quaisquer efeitos colaterais, tal que a mudança nunca ocorreu. Cada memória da XML 306 pode utilizar sua memória

ae anuraçào para desfazer as mudanças qn^ Aa fez. AlternaUvamente, a memória de anulação global 310 pode ser utilizada para desfazer as mudanças feitas através das memórias de dados. Imagine que existem três consumidores de dados que estão interessados no que está acontecendo nas propriedades do documento, então cada um. desses consumidores de dados se inscreveu para receber um evento relacionado com uma mudança das propriedades. Quando uma mudança é feita, a memória de dados determina cada consumidor de dados que se inscreveu e informa cada um deles da mudança em uma ordem predeterminada. Cada consumidor de dados, por sua vez, pode executar alguma ação em resposta à mudança. Se a mudança, ou qualquer uma das mudanças feitas pelos consumidores de dados inscritos como um resultado da mudança, não é aceita por qualquer um dos consumidores de dados, todas as mudanças relacionadas com a mudança inicial são desfeitas.

A camada de interface de programação da aplicação do agente externo 316 provê acesso à memória de dados 302 pelos consumidores de dados externos 318 e permite que cli20 entes de terceiros interajam com a memória de dados 302 justo como os consumidores de dados internos que são associados com a aplicação interagem com a memória de dados. Cada uma das memórias de dados da XML 306 dentro da memória de dados

302 é provida com um ID único para finalidades de identifi25 cação. Isso ajuda na localização das memórias de dados da XML 306.

Em qualquer ponto no tempo, um consumidor de dados pode adicionar um esquema que é usado para validar os dados

5

Centro ae uma memória de dados. QnanHo -nm esquema é adicionado e um consumidor de dados tenta mudar qualquer um dos dados, a memória de dados determina se a mudança faz sentido com o esquema provido. Depois que um esquema é anexado, o agente se torna um objeto de validação.

Esquemas da XML definidos sob encomenda podem ser usados para prover marcação semântica ao redor de conteúdos dentro de um documento, tais como um documento de processamento de texto, um documento de planilha e semelhantes. Essa funcionalidade poderosa permite que os desenvolvedores criem soluções que alavancam essa incorporação da XML sob encomenda para funcionar diretamente contra a estrutura e o conteúdo de seus dados ao invés de requerer que a sua solução lide com as complexidades do formato de apresentação da aplicação subjacente.

Por exemplo, se o usuário fosse criar uma página de cobertura para uma nota de pesquisa de equidade em uma aplicação que não fosse capaz da XML, então a extração dos dados úteis (por exemplo, o nome da companhia, o símbolo re20 gistrador do estoque, a avaliação do estoque) exigiría o uso do modelo do objeto da aplicação que está intimamente ligado ao formato de apresentação do documento. Isso necessariamente significaria que a lógica da solução resultante estava também ligada ao formato de apresentação do documento e su25 jeita à falha se essa apresentação fosse para mudar. Por exemplo, se o código espera que o símbolo registrador esteja na coluna 3, linha 2 da primeira tabela, a adição de uma nova línha/coluna rompería essa lógica. Com aplicações habili26

tadas em XML, entretanto, esse código nnde agora ser associado com a estrutura dos próprios dados do consumidor, removendo a necessidade da lógica ser ligada à apresentação. Essa mesma lógica poderia pesquisar os conteúdos do nó da XML <stockSymbol>, e encontrá-lo sempre que ele existisse no documento para editá-lo, mesmo se sua apresentação ccntextuai tivesse mudado drasticamente.

Um esquema da XML freqüentemente envolve vários tipos de dados, incluindo: metadados (por exemplo, dados do autor para armazenamento/processamento) , dados de corpo (por exemplo, a companhia sendo relatada) e dados de tabela (por exemplo, histórias de preço de estoque). Esses tipos de dados, entretanto, não são mutuamente exclusivos. Na realidade, eles são de forma geral regiões vastamente sobrepostas dentro do mesmo documento da XML. Idealmente, embora esses dados sejam todos expressos por um único esquema da XML, esses vários 'tipos' de dados poderíam ser editados cada um etc. em ambientes especificamente adequados para a expressão ótima desses dados. Por exemplo, um formulário poderia apa20 recer para permitir que o usuário facilmente editasse os metadados para o documento enquanto que o corpo do documento pode ser editado via uma aplicação de processamento de texto. Isso ocorre em tempo real, tal que o usuário poderia preencher partes do documento e formulário simultaneamente.

As memórias de dados podem também receber mais do que um elemento de cada vez. Prover os dados (XML) como um fluxo particular pode ajudar a satisfazer o esquema em algumas situações. Por exemplo, suponha que um esquema anexo diz

que se os aaaos cio estoque existem, deve ter peV duos compannias. Se os dados de estoque fossem adicionados um por um, isso não seria válido.

De acordo com uma modalidade, uma única passagem é 5 usada para validar os dados. Ao invés de fazer duas passagens que pode resultar em uma mudança sendo feita na memória de dados, a validação é executada antes que os dados sejam submetidos à memória de dados. Isso ajuda a impedir que um consumidor de dados introduza erros na memória de dados.

Como discutido aqui, os dados da XML que são associados com um documento podem agora ser armazenados separadamente de qualquer documento de aplicação especifico em uma memória de dados da XML central 302. Múltiplos ambientes podem ser criados para a apresentação/edição de um pedaço dos dados da XML. As expressões desses dados são automaticamente sincronizadas através de suas conexões nos mesmos dados na memória de dados da XML. Como tal, múltiplas aplicações podem simultaneamente exibir os mesmos dados da XML subjacentes. Isso significa que o usuário é concedido com a capaci20 dade de editar os mesmos dados na aplicação que é 'a melhor ferramenta para a tarefa'. Por exemplo, um formulário para editar a informação dos metadados, uma superfície do documento de processamento de texto para editar as seções de formulário livre dos dados, etc. Isso também significa que o usuário pode editar os dados em múltiplas aplicações como desejado. Se a mesma informação aparece em múltiplas aplicações, o usuário pode editar esses dados em qualquer uma delas como desejado com base no seu contexto de edição atual.

Embora cada aoi ·ί '-ar-ãr» arpra acesso simultâneo aos dados inteiros da XML que são associados com o documento, cada aplicação pode individualmente fazer a escolha de se exibir e editar qualquer parte desses dados. Isso sig5 nifica que cada aplicação precisa somente exibir as partes dos dados que são relevantes dentre desse contexto. Por exemplo, todos os dados da XML poderíam ser exibidos no documento, mas uma outra aplicação poderia somente estar interessada nos valores de um nó da XML dentro dos dados e, por10 tanto, precisa somente exibir essa parte dos dados sem se preocupar sobre o 'transporte' do resto da estrutura da XML para garantir o contexto.

O usuário pode editar os dados em qualquer aplicação exibindo a mesma informação da XML e imediatamente ter esses dados atualizados (junto com qualquer lógica de negócios aplicável} em todas as localizações que estão se referindo a essa parte dos dados. Essa capacidade de receber mensagens em tempo real para cada mudança da XML é útil, já que ela permite a criação de ambientes de edição que refle20 tem a natureza de sobreposição das várias exigências de edição dentro de um único documento da XML.

As aplicações podem também compartilhar informação de erro. Uma coleção definida pelo usuário de erros de conteúdo pode ser armazenada em cada memória de dados. Por e25 xemplo, a lógica do negócio pode ditar que um nó <startDate> deve ter um valor antes do nó <endDate>. A fim de permitir que múltiplos consumidores de dados compartilhem coletivamente os seus erros, uma memória de erro é incluída dentro

de Cãdâ UITl<3. dss rnernórí 5S da VMT <7ua> a ΓΓΓ.Ξ 1923 listic ds r.óc na XML + um erro (consistindo de texto de erro e um nome) . Assim como as mudanças da XML, um cliente pode criar um erro e essa mudança de erro é difundida para cada cliente suces5 sivamente. Como tal, múltiplas aplicações podem contar com uma única implementação para a lógica de validação ser compartilhada contra todas as representações desses dados. Em outras palavras, a mesma lógica não precisa ser replicada em cada aplicação que está exibindo os dados da XML.

Uma memória de anulação pode ser uma memória de anulação global 310 e/ou as memórias de anulação podem ser incluídas com cada memória da XML. Solicitações de mudança de cada consumidor de dados podem ser concatenadas em uma única pilha de anulação, tal coma memória de anulação 310, que combina cada mudança com todas as mudanças relacionadas, de modo que cada uma pode ser desfeita como uma unidade. Isso permite que todos os clientes solicitem a 'anulação' da última mudança inteira, mantendo todo o documento em um estado bom conhecido.

A sincronização dos dados não é limitada a um grupo predefinido estabelecido de consumidores de dados. Em outras palavras, novos consumidores de dados podem se inscrever para notificação em qualquer momento, em quaisquer dados da XML e imediatamente ser capazes de editar os mesmos dados como todos os outros clientes. Por exemplo, inicialmente somente os consumidores de dados externos 1 e 2 podem estar compartilhando os dados. Em um momento posterior, um ou mais consumidores de dados podem se inscrever com a memória de dados e

OS daÓOS.

começar a comoartirhar os dados.

Um consumidor ae dados age como o 'dcr.o' aos dados da XML e é responsável· por: manter a forma persistente des dados da XML, prover uma cópia dos dados para consumidores de dados soZicitantes, r-eceber solicitações de mudança para © -q q q ς rl cq η Ό R ’ ]Π·’ Ί p p r ρ ς rj Q Q ² 0 O ? R ^Γ ί 3 ^r Η ϊ <~Ή C C Θ S C 3 mudanças para os consumidores de dados inscritos. De acordo com uma modalidade, a memória de dados age como o dono e manipula toda a atualização e notificação para cada um dos consumidores de dados. A memória de dados da XML inclui um conjunto de interfaces que estão disponíveis para aplicações diferentes, tais como uma aplicação de processamento de texto, uma aplicação de planilha, um programa de apresentação de slide e outros consumidores de dados. As interfaces são direcionadas em: obter pedaços desejados dos dados da XML, notificar a memória de dados das mudanças que um consumidor de dados gostaria de fazer na memória de dados e inscrever para receber notificações da memória de dados da XML sobre mudanças feitas nesse item da memória por outros consumido20 res de dados.

Sempre que a memória de dados notifica um consumidor de dados sobre uma mudança, o consumidor de dados pode: não fazer nada e aceitar a mudança, solicitar uma ou mais mudanças de efeito colateral e rejeitar a mudança. As mudan25 ças de efeito colateral geralmente envolvem a adição de lógica que inicia mudanças em resposta a outras mudanças que são feitas na memória de dados. Por exemplo, um consumidor de dados que usa uma nota de pesquisa de equidade pode deseΖ t

jar receber notificação ausr.oo o nc <srock3viaboi/> dentro ca memória de dados é alterado, e em resposta à mudança submete os cacos a um serviço oe rede e tt.ca . _.za a subarvore tstccKData/> que está dentro de uma memória de dados.

Mudanças de efeito colateral são agrupadas com. a mudança original coro as finalidades de desfarer/cancelar e elas são manipuladas diferentemente pela memória de dados. Elas são manipuladas diferentemente desde que as mudanças de efeito colateral são solicitadas em resposta a uma mudança que não foi ainda ela própria submetida à memória de dados da XML.

Se um consumidor de dados (314 e/ou 318) solicita uma mudança na memória de dados da XML 302, essa mudança pode ser rejeitada por razões diferentes, incluindo: a mudança é inválida (por exemplo, XML que não é bem formada) , a mudança foi rejeitada por alguma lógica dentro de um consumidor de dados e semelhantes.

Alguns consumidores de dados podem manter sua própria versão dos dados em uma memória 320 que é mantida separadamente da memória de dados da XML 302. Manter múltiplas cópias desses dados da XML pode levar a problemas, incluindo que as cópias podem sair de sincronismo (por exemplo, o 'título' no painel de propriedade não iguala o 'título exibido em linha no documento). Para tratar esse problema, uma única cópia mestre de cada pedaço dos dados da XML é mantida durante uma sessão. Essa cópia mestre é então usada por múltiplos consumidores de dados durante uma sessão. Quando a sessão termina, as outras cópias dos dados podem ser atualiza32

das para refiemr o estado atual da memória de dados da XML. De acordo com uma modalidade, a memória de dados 302 é configurada para intercalar os mesmos itens das memórias de dados diferentes e depois salvar cada cópia de volta em um mo5 mento posterior. Quando uma solicitação para um item de dados comum é recebida, a memória de dados 302 encobre esses dois itens da memória de dados em um único nó principal, cria um XSD intercalado que importa os esquemas que são associados com cada item de dados e entrega a interface para esse item de memória para o consumidor de dados.

A memória de dados 302 é configurada para detectar recursão excessiva e quando detectada, causar uma falha automática se a memória de dados detecta um laço de efeitos colaterais em resposta a uma dada mudança. De acordo com uma modalidade, um laço que excede 16 níveis em profundidade ou

1000 efeitos colaterais totais é considerado excessivo. A memória de dados pode também ser configurada para rejeitar automaticamente qualquer mudança e seus efeitos colaterais, quando é verificado que a mudança é estruturalmente inválida pela memória de dados da XML. Isso significa que se uma mudança estrutural é solicitada por um usuário e verificada como sendo estruturalmente inválida, então a memória de dados se restaura para o último estado bom conhecido e produz um erro que pode ser passado para os outros consumidores de dados.

Cada consumidor de dados (interno 314/externo 318) pode também rejeitar mudanças inválidas. Por exemplo, um consumidor de dados pode incluir sua própria camada de vali3 3 dação. 3e uma mudança e soncuacta dentro de um consumidor de daaos que e inválido, essa mudança pode ser rejeitada por sua camada de validação existente e revertida de sua própria memória de dados sem notificar a memória de dados da XML. Se essa mudança se originou da memória de dados da XML, então o consumidor de dados retorna uma rejeição para o mmmo atirado pela memória de dados e a memória de dados inicia um cancelamento para seu 'último estado bom conhecido'.

No caso de mudanças solicitadas por outros consu10 midores de dados para a memória de dados, a memória de dados tenta validar essas mudanças se ela tem uma coleção de esquema da XML 305 associada com os dados atuais. Se esquemas estão presentes, então a memória de dados rejeita quaisquer inválidos estruturalmente.

A fim de suportar a ligação dos dados, o consumidor interno dos dados de aplicação, tal como o consumidor interno de dados 1 314, manipula a interação entre as ações na memória de dados da XML e na superfície do documento 315. Quando um usuário edita um campo ligado de dados, essa mu20 dança afeta o conteúdo do documento (assim adicionando um registro na pilha de anulação da aplicação), mas também afeta o conteúdo da XML da memória de dados (assim adicionando um registro na pilha de anulação da memória de dados). A fim de ajudar a garantir que a superfície e os dados permaneçam em sincronismo em todos os momentos, a pilha de anulação da aplicação (com a qual o usuário interage) é capaz de 'agrupar' mudanças de superfície em um registro de anulação, junto com uma referência de anulação da memória de dados da XML

cor resoondente, garantindo aue a anulação do Έρο ςηροΗηκ em cada pilha mantenha a aplicação e a memória de dados em um estado idêntico.

Alternativas diferentes estão disponíveis para lidar com a anulação iniciada pelo usuário, incluindo: manter

Dilhas de anulação seoaradas rara cada consum.

incluindo a aplicação hospedeira, compartilhar uma pilha de anulação global e limitar a anulação para um consumidor de dados com base no foco atual.

Quando uma pilha de anulação global é usada, o consumidor de dados passa através das solicitações de anulação diretamente para a aplicação hospedeira, que então pega o último item fora da sua pilha de anulação (anulação seria a mesma a despeito de onde o foco estava no quadro da apli15 cação). Isso implica que todas as mudanças na memória de dados da XML são afuniladas sobre a pilha de anulação do hospedeiro com algum registro genérico (por exemplo, desfazer propriedade de edição). Por exemplo, se o usuário digita Microsoft Corp. no campo <company/> em uma aplicação de processamento de texto, então essa operação faz com que a pilha de anulação da memória de dados inclua essa ação. A seguir, se o usuário fosse pressionar desfazer na aplicação de processamento de texto para remover esse texto, a aplicação de processamento de texto desfaz a última operação na sua pilha de anulação (e notifica a memória de dados para desfazer a última operação na sua pilha), o que resultaria no outro cliente fazendo essa ação. Inversamente, se o usuário então tivesse digitado algum texto nao ligado na aplica35

ção de processamento de texto e pressionado desfazer m painel, o outro cliente abandonaria essa solicitação para o hospedeiro, que removería a última ação da sua pilha de anulação (nesse caso, a edição para a superfície do documento):

Quando um consumidor de dados rejeita uma mudança enviada oela memória de dados da XML, 03 dados da XML podem terminar em um estado lógico de negócios 'ruim'. Por exemplo, assuma que exista lógica de negócios que executa verificações em um relatório de despesa. A lógica inclui verifi10 car se um item da linha está acima de $100; e se afirmativo, o consumidor de dados rejeita a atualização de ClineltemAmount/>. Se não, o consumidor de dados atualiza o total com a nova quantidade do item da linha. Se o total está acima de $500, então o consumidor de dados rejeita a atualização de <reportTotal/>. Agora usando a lógica acima, assuma que um usuário insere uma linha de fatura de $50 que move o total acima de $500, a primeira verificação da lógica é bem sucedida, mas a segunda verificação da lógica rejeita a atualização do total. Isso significa que se apenas a última mudan20 ça foi desfeita, então existiría uma fatura onde a soma dos itens da linha não iguala o total. Como um. resultado, de acordo com uma modalidade, todos os efeitos colaterais da mudança original são desfeitos.

A memória de dados 302 age como um mecanismo de transação que permite o agrupamento dessas transações com as finalidades de anulação. De acordo com a modalidade, três alternativas diferentes para manipular as 'rejeições' são usadas. Primeiro, a memória de dados pode emitir mudanças de <

anulação para retornar para um esrado vglifp (i-At-pr chamado 'reversão'). Segundo, anulação e cancelamento não têm paridade e terceiro, nenhum cliente é capaz de cancelar.

A primeira alternativa é ter a memória de dados da 5 XML emitindo mudanças de anulação para retornar para um. estado válido. Isso essenciaimente desfaz todas as operações de volta para a mudança que disparou o erro da lógica do negócio. Nessa alternativa, a memória de dados da XML poderia emitir solicitações de mudança com um indicador de 'anula10 ção' ajustado para VERDADEIRO e ter o consumidor de dados executando essas mudanças por si próprio; e a memória de dados da XML poderia emitir solicitações de mudança com esse indicador de 'anulação' ajustado. O seguinte é um exemplo.

O usuário edita o nó A em um cliente 1 { (Cliente 1 faz a lógica interna)

Informar memória de dados da XML {

Armazenar atualizações

Informar cliente 2 sobre A {

Mudar B (

Enfileirar, retornar OK

Informar cliente 1 sobre B {

Lógica interna

Mudar C {

Lógica interna

Informar memória de dados da XML {

Enfileirar, retornar OK

t

OAC }

}

Informar cliente 2 sobre C i

Mudar D ¹

Enfileirar, retornar OK }

)

Informar cliente 1 sobre D ( Lógica interna **REJEIÇÃO**

Reverter mudança DOM para D

Retornar FALHA }

Informar	cliente	2	para	desfazer	D
Informar	cliente	2	para	desfazer	C
Informar	cliente	1	para	desfazer	C - *desfazer en

quanto saindo depois de uma rejeição

Informar cliente 1 para desfazer B - *desfazer enquanto saindo depois de uma rejeição

Informar cliente 2 para desfazer B Informar cliente 2 para desfazer A

Retornar FALHA para solicitação de mudança inicial }

Essencialmente, o consumidor de dados aceita as duas chamadas da memória de dados da XML (solicitações para

desfazer mudanças de B e C ennnantr, caindn de mudança principal A) ou senão os dois gerentes do objeto do documento da

XML saem de sincronísmo.

Uma outra alternativa é manter a disparidade atual 5 entre cancelar e desfazer, à medida que ter o consumidor de dados 'cancelando' a mudança atual pode deixar a solução em um estado lógico de negócios inválido. Nesse caso, a memória de dados da XML reverte *somente* a mudança que foi rejeitada/cancelada, desfazendo essa mudança, mas então apenas pa10 raria - não desfazendo quaisquer mudanças adicionais que estão na pilha de anulação da memória.

Consumidores de dados podem também manter suas próprias pilhas de anulação únicas. As aplicações, entretanto, devem ser 'inteligentes' sobre não adicionar ações adi15 cionais nas suas pilhas de anulação quando a ação mais superior na sua pilha iguala a operação solicitada do outro lado do limite de sincronísmo ativo. Por exemplo, se o usuário digita Microsoft Corp no campo <company/> na aplicação de processamento de texto, então essa operação será 'sincroní20 zada ativa' e resultará em uma ação de anulação aparecendo na pilha de anulação de cada consumidor de dados registrado. A seguir, se o usuário fosse pressionar desfazer na aplicação de processamento de texto para remover o texto que foi recentemente inserido, a aplicação de processamento de texto desfaria a última operação na sua pilha de anulação (e informaria a memória de dados para desfazer a última operação na sua pilha), mas nesse momento o consumidor de dados veria essa solicitação e adotaria a última ação da sua pilha de

Ο / Ό anulação (inciuindo quaisquer efeitos coiareraisi porque a pilha de anulação oa memória deve necessariamente igualar a memória de dados. Se o usuário tivesse então pressionado desfazer no consumidor de dados, o consumidor de dados removería a última ação da sua cilha de anulação e da aplicação de processamento de texto, aⁿ obter a ação de anulação da memória de dados, percebería que ela iguala a última ação na sua pilha de anulação e removería essa também. Inversamente, se o usuário tivesse então digitado algum texto não ligado na aplicação de processamento de texto (adicionando registros de anulação na aplicação de processamento de texto) antes que eles pressionassem desfazer no consumidor de dados, o cliente removería a última ação da sua pilha de anulação e a memória faria o mesmo, entretanto, a aplicação de processamento de texto adiciona uma outra ação (porque a última coisa na pilha de anulação não é a última mudança da XML) . Entretanto, a aplicação de processamento de texto armazenaria essa mudança junto com o fato que a memória precisa executar um refazer para retornar para o seu estado original.

Uma outra alternativa envolve tornar os consumidores de dados cientes um do outro. O controle de anulação poderia ser passado entre os consumidores de dados. Por exemplo, se o usuário edita o campo <company/> em uma aplicação, que é então difundida para um outro consumidor de dados, então a pilha de anulação se parecería com;

A Ο

dad^s da XML nãc hospedaria a transação. Preferivelmente, ele hospedaria um marcador que permitiría que ele passasse o controle para o cliente para completar a ação de anulação.

Assumindo que o usuário então fosse para a aplicação de processamento de texto e executasse uma anulação: a tela da aplicação atualizaria de volta e a seguir passaria o controle para a memória de dados. A memória de dados da XML tentaria desfazer a última transação, porém veria o marcador e passa10 ria o controle para o consumidor de dados para essa anulação. O consumidor de dados executaria a solicitação de anulação para a memória, que então a difundiría como uma anulação para todos os outros clientes. Isso significa que se o usuário executasse uma ação no cliente, seguido por uma ação em um campo diferente na aplicação de processamento de texto, as pilhas de anulação se pareceríam com:

Memória	Aplicação	Consumidor de dados 1
Marcador (passagem para Processo 1)	Companhia -> Microsoft Corp. + desfazer memória	Companhia -> Microsoft Corp
Data -> 20 de janeiro de 2005	Data -> 29 de janeiro de 2005 + desfazer memória	marcador (passagem para hospedeiro)

Nesse caso, se a próxima ação rin usuário fosse uma anulação na aplicação hospedeira, então o hospedeiro (e a memória de dados) faria a ação de anulação, que o consumidor de dados executaria no seu próprio DOM e se desfaria do mar5 cador de anulação, Se a próxima ação do usuário fosse uma anulação no consumidor de dados, então o consumidor de dados daria o controle para essa ação para o hospedeiro (porque a ação superior é apenas um 'marcador' ) e a mesma anulação do hospedeiro seria executada,

A figura 4 ilustra um exemplo da sincronização ativa. Em um dos casos mais simples, 'sincronização ativa' se refere à capacidade das edições do usuário dos dados da XML apresentados em uma localização (por exemplo, uma aplicação de processador de texto) serem refletidas na UI de uma outra localização/aplicação em tempo real. Enquanto o documento está sendo editado, mudanças que afetam os dados da XML são passadas para os outros consumidores de dados registrados que estão interessados nos dados, tal como ambos a aplicação de processamento de texto e o painel de propriedade. Isso ajuda a garantir que o conteúdo dos dados da XML de cada aplicação permaneça o mesmo.

Com referência à janela 400, um documento 415 é aberto para edição e um painel de propriedade 420 está mostrando. O título é mostrado em ambos o painel de propriedade

405, bem como no documento 410. Suponha que o título 405 na janela 400 é alterado de Data Binding - Live Sync Integration para Foo Bar Biz, como ilustrado no título 435 e título

440 dentro da janela 425. Tão logo o título seja atualizado

dentro do titulo do painel Ho propriedade 4 35, 2 mudança ó enviada para a aplicação de processamento de texto tal que ela pode aceitar ou rejeitar a mudança. Nesse exemplo, a aplicação aceitou a mudança para o título que foi feita usan5 do a aplicação do painel de propriedade e o título 440 dentro do documento é atualizado.

As figuras 5-8 ilustram processos para sincronização em tempo real dos dados da XML entre consumidores de dados .

Quando lendo a discussão das rotinas apresentadas aqui, deve ser verificado que as operações lógicas de várias modalidades são implementadas (1) como uma seqüência de ações implementadas no computador ou módulos de programa funcionando em um sistema de computação e/ou (2) como circuitos lógicos de máquina interligados ou módulos de circuito dentro do sistema de computação. A implementação é uma questão de escolha dependente das exigências de desempenho do sistema de computação implementando a invenção. Dessa maneira, as operações lógicas ilustradas e compondo as modalidades do aqui descrito são citadas variavelmente como operações, dispositivos estruturais, ações ou módulos. Essas operações, dispositivos estruturais, ações e módulos podem ser implementados em software, em firmware, em lógica digital de uso especial e qualquer combinação desses.

A figura 5 ilustra a interação entre dois clientes e uma memória de dados da XML.

A memória de dados 520 recebe uma edição do usuário para o nó A feita usando a aplicação 510. O consumidor

de aados 1 530 recebe a notificação da mudença para c nó A da memória de dados 520. Como nm resultado da mudança para o nó A, o consumidor de dados 1 solicita uma mudança de efeito colateral para o nó B. A memória de dados 520 enfíleira a mudança de efeito colateral B para execução pos-.eri.or, Depois que todas as mudanças de efeito colateral foram enfileiradas do consumidor de dados 1, a memória de dados 520 notifica o consumidor de dados 2 540 da mudança para o nó A. 0 consumidor de dados 2 solicita uma mudança de efeito cola10 teral para o nó C. Em resposta, a memória de dados enfileira a mudança do nó C para execução posterior. Nesse momento, o processamento relacionado com o nó A concluiu, mas ainda existem mudanças de efeito colateral pendentes para o nó B e para o nó C. Como o consumidor de dados 1 solicitou a mudan15 ça para o nó B, a memória de dados envia a notificação da mudança proposta de B para o consumidor de dados 2. O consumidor de dados 2 não faz quaisquer mudanças em resposta e aceita a mudança. Similarmente, o consumidor de dados 2 solicitou a mudança para o nó C, então a memória de dados en20 via a notificação da mudança do nó C para o consumidor de dados 1. 0 consumidor de dados 1 aceita a mudança. Nesse exemplo, todas as mudanças foram aceitas por todos os consumidores de dados interessados. Portanto, a memória de dados submete as mudanças para a memória de dados. Em resumo, a memória de dados permite que cada consumidor de dados execute quaisquer mudanças em resposta a uma mudança, a memória de dados executa e transmite mensagem, dessas mudanças na ordem que elas são recebidas, dessa maneira permitindo que e44

las sejam transmitidas serialmente.

A figura 6 mostra a interação entre dois consumidores de dados externos e uma mudança na memória de dados da

XML.

No caso onde a mudança original foi gerada por um cliente interno, tal como a aplicação que criou c documento mostrado na figura 5, o consumidor de dados muda ligeiramente. Esse exemplo ilustra duas regras básicas de mudanças de múltiplos clientes. A primeira regra é que as mudanças de nível superior ocorrem primeiro. A segunda regra envolve o enfileiramento das mudanças de efeito colateral.

A primeira regra se refere ao fato que os efeitos colaterais de uma mudança acontecem antes que qualquer nova mudança possa ocorrer. Considere o exemplo seguinte, onde o consumidor de dados 1 executa uma função para fazer duas mudanças. A primeira mudança é feita no nó A e a segunda mudança no nó B.

Quando o consumidor de dados 1 630 solicita uma mudança no nó A, a notificação é enviada para o consumidor de dados 2 640 depois que a memória de dados da XML 620 recebe a solicitação para mudar o nó A. Em resposta, o consumidor de dados 2 solicita uma mudança de efeito colateral para o nó C que é enfileirada pela memória de dados para execução posterior. O consumidor de dados 1 então solicita uma mudança para o nó B que é enfileirada desde que a mudança para o nó A ainda não foi concluída. O consumidor de dados 2 aceita a mudança para o nó A, e em resposta, a memória de dados executa a mudança de efeito colateral enfileirada

para C. 0 consumidor de dados 1 recebe a notificação ria mudança para o nó C e pode responder à mudança. Nesse exemplo, o consumidor de dados 1 aceita a mudança, A memória de dados então executou a mudança de efeito colateral enfileirada pa5 ra B que foi solicitada pelo consumidor de dados 1. 0 consumidor de dados 2 recebe a notificação da mudança B da memória de dados para a qual ele pode responder. 0 consumidor de dados 2 aceita a mudança e as mudanças são submetidas para a memória de dados.

Nesse caso, o consumidor de dados 2 responde primeiro para a mudança em A, de modo que as duas linhas seguintes do código disparam duas mudanças únicas:

doc.CustomXMLParts(1).SelectSingleNode{).AddNode( foo,bar) doc.CustomXMLParts(1).SelectSingleNode{).AddNode( foo2,bar)

Uma segunda regra se refere ao fato que os efeitos colaterais de uma mudança são enfileirados quando eles são solicitados e, portanto, múltiplas mudanças podem ser enfileiradas antes que os efeitos colaterais da primeira mudança ocorram.

A figura 7 mostra um processo envolvendo múltiplas mudanças de efeito colateral. O exemplo seguinte ilustra as mudanças seguintes. Suponha que o consumidor de dados 1 730, quando ele recebe uma notificação que o nó A é alterado, deseja executar mudanças de efeito colateral nos nós B e C. O

consumidor ae dados 2 740, em resoosta à notificação da mudança para o nó B, deseja executar mudanças de efeito colateral nos nós D, E e F.

Com referência à figura 7, pode ser observado que o consumidor de dados 1 causa rodas as suas mudanças de efeito colateral como um resultado da notificação da mudança para o nó A antes que os efeitos colaterais relacionados com a mudança do nó B sejam executados. Portanto, as mudanças no nó C ocorrem antes das mudanças nos nós D, E e F.

A figura 8 ilustra um processo mostrando que os efeitos colaterais do chamador são executados por último. Uma pessoa pode ainda observar que nesse caso, os efeitos colaterais gerados pelo próprio consumidor de dados 1 acontecerão depois que todos os outros clientes tenham tido uma chance de ver a mudança e gerar seus próprios efeitos colaterais. Isso é um efeito colateral necessário do fato que a memória de dados da XML informa cada cliente de uma mudança (para garantir que cada cliente tenha uma chance de aceitar/rejeitar essa mudança) antes que ela possa retornar a condição de sucesso para o chamador e permitir que o chamador proveja o evento com o qual fazer os efeitos colaterais. É previsível· que o consumidor de dados que solicitou uma mudança deva ser o último, de modo a saber se a mudança foi aceita ou rejeitada por todos os clientes da memória de da25 dos da XML. Também, isso ajuda a garantir que se as duas mudanças são conflitantes e não estruturais, a mudança do chamador obtém o que é geralmente o resultado desejado.

O relatório descritivo acima, exemplos e dados p r οvêem s i ça o da

ma descrição completa da faoricacão e cso da oompr'·invenção.

Claims (20)

1. REIVINDICAÇÕES

   1. Meio legível por computador, contendo instruções executáveis por computador para sincronizar itens de dados estruturados que são associados com um documento

   5 gerado pelo computador e que são compartilhados através de consumidores de dados, os consumidores de dados sendo aplicativos executáveis por computador, o método de sincronização compreendendo armazenar itens de dados estruturados que são associados com um documento em uma memó10 ria de dados, onde a memória de dados é separada do documento, o método de sincronização caracterizado por:

   iniciar uma mudança em um item de dados estruturado dentro da memória de dados por um primeiro consumidor de dados, o item de dados estruturado compreendendo

   15 múltiplos pedaços de dados estruturados, dita mudança ocorrendo sobre ao menos um pedaço de dado estruturado;

   determinar se existem outros consumidores de dados que estão interessados na mudança no item de dados estruturados, sendo que a determinação ocorre caso os ou20 tros consumidores de dados registrem através de uma API, uma solicitação de notificação de mudança no item de dados estruturado;

   notificar os outros consumidores de dados da mudança, onde os outros consumidores de dados podem execu25 tar pelo menos um dentre: aceitar a mudança, rejeitar a mudança e iniciar uma mudança de efeito colateral como um resultado da mudança original, na qual a mudança de efeito colateral é uma mudança iniciada por um dos outros

   Petição 870180046273, de 30/05/2018, pág. 4/15 consumidores de dados em resposta à mudança iniciada pelo primeiro consumidor de dados, sendo que ao menos uma das mudanças é uma mudança sobre um outro pedaço dos pedaços de dados estruturados; e submeter a mudança iniciada pelo primeiro consumidor de dados e qualquer mudança colateral iniciada à memória de dados quando a mudança é aceita e reverter a memória de dados para um estado antes do momento quando a mudança foi iniciada quando a mudança é rejeitada.
2. 2. Meio legível por computador, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende estruturar os itens de dados estruturados dentro da memória de dados de acordo com as especificações da linguagem de marcação extensível (XML).
3. 3. Meio legível por computador, de acordo com a reivindicação 2, caracterizado pelo fato de que ainda compreende expor uma interface de programação de aplicação (API) aos consumidores de dados que permite o acesso programático aos itens de dados estruturados; onde a API proporciona a capacidade de acessar os itens de dados estruturados dentro da memória de dados enquanto o documento está aberto e onde a API permite que mais de um consumidor de dados acesse um mesmo item de dados estruturados ao mesmo tempo; e onde a API proporciona aos consumidores de dados a capacidade de se inscrever para uma notificação que envolve um ou mais dos itens de dados estruturados.
4. 4. Meio legível por computador, de acordo com a de 30/05/2018, pág. 5/15 reivindicação 3, caracterizado pelo fato de que ainda compreende atualizar uma exibição que está associada a um dos outros consumidores de dados com um valor do item de dados estruturados que foi alterado pelo primeiro consumidor de dados.
5. 5. Meio legível por computador, de acordo com a reivindicação 4, caracterizado pelo fato de que a mudança do efeito colateral é enfileirada para execução posterior, onde a execução posterior ocorre depois que cada um dos consumidores de dados tiver tido uma chance de aceitar, rejeitar e fazer uma mudança de efeito colateral.
6. 6. Meio legível por computador, de acordo com a reivindicação 4, caracterizado pelo fato de que submeter a mudança quando aceita compreende processar cada efeito colateral e determinar se cada efeito colateral é aceito.
7. 7. Meio legível por computador, de acordo com a reivindicação 4, caracterizado pelo fato de que ainda compreende manter uma lista de anulação que pode ser usada para retornar a memória de dados de volta para o estado antes do momento quando a mudança foi iniciada.
8. 8. Método implementado por computador para compartilhar itens de dados estruturados entre consumidores de dados, os itens de dados estruturados sendo associados com documentos gerados pelo computador, os consumidores de dados sendo aplicativos consumidores de dados executáveis em computador, o método caracterizado por:

   iniciar, por um primeiro consumidor de dados, uma mudança em um item de dados estruturados que estão de 30/05/2018, pág. 6/15 contidos dentro de uma memória de dados e estão associados com um documento, onde o item de dados estruturados é estruturado de acordo com uma linguagem de marcação extensível (XML) e onde a memória de dados e separada do documento, o item de dados estruturados compreendendo múltiplos pedaços de dados estruturados, a mudança ocorrendo ao menos sobre um dos pedaços de dados estruturados;

   proporcionar a notificação da mudança para consumidores de dados inscritos;

   enfileirar as mudanças de efeito colateral iniciadas por outros consumidores de dados inscritos em resposta à mudança iniciada pelo primeiro consumidor de dados, para processamento posterior, determinar quando uma resposta de um dos consumidores de dados inscritos é uma rejeição da mudança, e no caso da resposta ser uma rejeição, reverter a mudança iniciada pelo primeiro consumidor de dados e quaisquer mudanças de efeito colateral de todos os consumidores de dados dentro da memória de dados para um último estado bom conhecido; e determinar quando cada um dos consumidores de dados inscritos aceita a mudança, e caso cada um dos consumidores de dados inscritos aceite a mudança, validar a mudança usando um arquivo de esquema XML que é provido por um dos consumidores de dados através de uma API e submeter a mudança iniciada pelo primeiro consumidor de dados e quaisquer mudanças de efeito colateral de todos os consumidores de dados para a memória de dados.

   de 30/05/2018, pág. 7/15
9. 9. Método implementado por computador, de acordo com a reivindica9ao 8, caracterizado pelo fato de que iniciar a mudança em um item de dados estruturados que está contido dentro da memória de dados compreende expor uma interface de programação da aplicação (API) que provê a capacidade para os consumidores de dados acessarem os itens de dados estruturados dentro da memória de dados, onde a API permite que mais do que um dos consumidores de dados acesse um mesmo item de dados estruturados ao mesmo tempo.
10. 10. Método implementado por computador, de acordo com a reivindicação 9, caracterizado pelo fato de que também compreende receber uma mudança de efeito colateral em resposta a notificação e retardar a execução da mudança do efeito colateral dentro da memória de dados até que a mudança tenha sido processada.
11. 11. Método implementado por computador, de acordo com a reivindicação 10, caracterizado pelo fato de que também compreende enfileirar a mudança do efeito colateral dentro da memória de dados.
12. 12. Método implementado por computador, de acordo com a reivindicação 10, caracterizado pelo fato de que determinar quando cada um dos consumidores de dados registados aceita a mudança compreende determinar quando a mudança é aceita por cada consumidor de dados e quando cada uma das mudanças de efeito colateral é aceita.
13. 13. Método implementado por computador, de acordo com a reivindicação 10, caracterizado pelo fato de que de 30/05/2018, pág. 8/15 ainda compreende manter uma lista de anulação que é usada para retornar a memória de dados de volta para o último estado bom conhecido.
14. 14. Sistema para sincronizar os itens de dados estruturados que são associados com um documento gerado por computador entre consumidores de dados, os consumidores de dados sendo aplicativos executados por computador, o sistema caracterizado pelo fato de que compreende:

    um consumidor de dados interno (314) que é configurado para criar e editar o documento e que é configurado para interagir com os itens de dados estruturados que são associados com o documento gerado em computador;

    consumidores de dados externos (318) que são configurados para interagir com itens de dados estruturados que são associados com o documento gerado em computador; e uma memória de dados (302) que é configurada para armazenar os itens de dados estruturados que são associados com o documento gerado em computador separado do documento gerado em computador, onde a memória de dados compreende: um agente da API que é configurado para interagir com os consumidores de dados externos e os consumidores de dados internos e que é configurado para receber uma mudança proposta para ao menos um dos itens de dados estruturados e, em resposta à mudança proposta, notificar consumidores de dados inscritos da mudança proposta, submeter a mudança à memória de dados quando a mudança proposta é aceita e quando a mudança proposta não é aceita, de 30/05/2018, pág. 9/15 garantir que a memória de dados fique em um estado válido, o item de dados estruturado compreendendo múltiplos pedaços de dados estruturados, a mudança sendo relativa ao pelo menos um dos pedaços de dados estruturados, onde

    5 a memória de dados também inclui uma memória de mudança que é configurada para armazenar a mudança iniciada pelo primeiro consumidor de dados e mudanças de efeito colateral que são iniciadas por consumidores de dados inscritos em resposta à mudança iniciada pelo primeiro consumidor

    10 de dados e uma memória de anulação que é configurada para reverter a memória de dados para o estado válido.
15. 15. Sistema, de acordo com a reivindicação 14, caracterizado pelo fato de que também compreende estruturar os itens de dados estruturados dentro da memória de

    15 dados de acordo com uma linguagem de marcação extensível (XML).
16. 16. Sistema, de acordo com a reivindicação 15, caracterizado pelo fato de que a memória de dados é ainda configurada para enfileirar as mudanças de efeito colate20 ral para execução posterior, em que a execução posterior é configurada para ocorrer depois que cada consumidor de dados inscrito ter tido a chance para aceitar, rejeitar e fazer uma mudança de efeito colateral.
17. 17. Sistema, de acordo com a reivindicação 16,

    25 caracterizado pelo fato de que a memória de dados é ainda configurada para processar cada efeito colateral e determinar se cada efeito colateral é aceito.
18. 18. Sistema, de acordo com a reivindicação 16,

    Petição 870180046273, de 30/05/2018, pág. 10/15 caracterizado pelo fato de que a memória de dados é também configurada para:

    receber uma mudança nos dados de marcação da linguagem de marcação extensível (XML) aplicada no item

    5 de dados estruturados, ler um arquivo de esquema da XML associado com o item de dados estruturados para o qual a mudança dos dados de marcação da XML é direcionada, determinar se a mudança nos dados de marcação da 10 XML é válida de acordo com o arquivo de esquema XML lido;

    e proibir a mudança nos dados de marcação XML se a mudança nos dados de marcação XML não é válida de acordo com o arquivo do esquema da XML lido; e submeter a mudan15 ça quando a mudança nos dados de marcação XML é válida de acordo com o arquivo de esquema da XML lido.
19. 19. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de que a memória de dados compreende uma pluralidade de memórias de dados da XML, em que
20. 20 cada uma compreende uma memória de anulação e uma memória de mudança.

    20. Sistema, de acordo com a reivindicação 19, caracterizado pelo fato de que cada memória de anulação é configurada para se comunicar com as outras memória de

    25 anulação.

    Petição 870180046273, de 30/05/2018, pág. 11/15 ζ

    /3

    Í72 !Α '

    Fí^.2 f

    300

    Documento

    315

    Meno. ãnu......-lacão.

    Consumidoi de dados internos ] 314

    Consumidor de ciados internos 1

    314 ünsumidoi' de dados internos

    314

    ». dfcí erra

    Mlb. ÚJILICamada de apresentação 3()4

    Esquea(s) da XML

    305 lacão

    306 ΐΒΐυ'. tfe¹· erra ou: 'ãhLP lacão

    N

    306

    Agente interno (API)

    3Í2

    Agente externo (API) 3Jg

    Memó- 1 Memó-| ria de ria 1 mudan- ' de , ça 1 anu- | lação’ 308 1 310 _j

    Memória de dados

    302

    Consumidor de dados externos 1

    313

    Consumidor de dados externos 2

    313

    Consumidor de dados externos' N

    318

    Memória da XML fíS.3

    320

    F*r tdfc vw hwl fei^ TeuU T*w« tnrtiev * : * w * x o a «> p » Ííle: CÚt« fkifnç -liw 5ync 4\>405

    Word fa0fr 5tOJM<

    ίιΜΤϊ ijuMàúf»;

    t\,420

    TristaaOasni

    Be«9u jat Data Binding - Live Sync lníegration l:j· t -.^Jyv.í. . lL.-T/rCj-í lr.'?T ή

    4\,4?5

    3 Significant changes mada afterthe Raview wlll be roted in Graen, like this is. ΐ sígnificant changes made after the Critique wül bs noted in Yeilow, like this is.

    ISigntffcant bug changes after Coding starts wfl hs noted in Red, like this is, Signifcent ÇtÇJ&g. after Code complete wili be noted in Black, like this is.

    1 Abstraot.................................................................................................2 £ OverView & Scope........................ z

    3 Defirtitions.................................................... ,2

    4 Prototype............................... 2

    5 coais...................,,,......................................................................;..z et! tda tfw nw! Am TUM Teta W.ln.i U X ΰ .1 *9 Ç» f*ttwí Ue ***, : .·.·.· ; ·, vz:.-“ / _r «₄ ;A.·. a‘,«. ^ÇráWtyifjéSS^^WA::

    ^Λ 440

    3 Signifca/ft changes made after the Rbvibw will be ncted in Green, like this s. J .·: Significant chances made afterthE Critique will be noted in Yeilow, lifce this is.

    ISignifc-ant buo changes after Coding Starts wi) be ncted in Red, like this ;s. 1

    Signifcent ββ?£ after Code Completo wif! be note d in Black, like this is. - | ’ l Abstraot,,............................................................................. 2 .2 OverView Br Eeope.......................................... 2

    3 Derinitiorrs................................................... 2

    4 Praioty pe............ £

    5 Gdals.....................................................................................................2

    ¢.

    ÍUK