СОВМЕСТНАЯ РАБОТА МНОЖЕСТВЕННЫХ КЛИЕНТОВ ДЛЯ ОСУЩЕСТВЛЕНИЯ ДОСТУПА И ОБНОВЛЕНИЯ СТРУКТУРИРОВАННЫХ ЭЛЕМЕНТОВ ДАННЫХ

Предшествующий уровень техники

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

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

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

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

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

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

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

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

Фиг. 3 представляет собой объединенный блок, данные и блок-схему последовательности операций процессов для предоставления возможности клиентским системам применять локальные спецификации к структурированным элементам данных.

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

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

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

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

Подробное описание

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

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

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

Фиг. 1 иллюстрирует системы или операционные среды, обозначенные, в общем, позицией 100, которые дают возможность множественным клиентским системам совместно осуществлять доступ и обновлять структурированные элементы данных. Эти системы 100 могут включать в себя одну или более серверных систем 102, причем фиг. 1 предоставляет два примера серверов под позицией 102a и 102n (совместно, серверы 102). Однако варианты реализации настоящего описания могут включать в себя любое число серверов.

Серверы 102 могут осуществлять связь с одной или более клиентскими системами 104, при этом фиг. 1 предоставляет два примера клиентских систем, отмеченных позициями 104a и 104n (совместно, клиентские системы 104). Сервер и клиентские системы могут осуществлять связь друг с другом по одной или более сетям 106, которые могут представлять собой локальные или глобальные сети, созданные с использованием любых подходящих технологий сигнализации и организации сетей. Сеть 106 может включать в себя, например, Интернет. Эти сети могут обеспечивать возможность беспроводной и/или проводной связи.

Серверы и клиенты могут осуществлять связь с сетями 106 через подходящие линии 108 связи. Фиг. 1 иллюстрирует линии 108a, 108b, 108c и 108n связи, ассоциированные, соответственно, с серверами 102a и 102n и клиентами 104a и 104n. Эти линии 108 связи представляют аппаратные и/или программные компоненты, которые позволяют серверам и клиентским системам подсоединиться к сетям. Эти компоненты могут включать в себя сетевые адаптеры, стеки протоколов и тому подобное.

Графические элементы, используемые на фиг. 1 для обозначения серверов, клиентских систем и сетей, выбраны только для того, чтобы облегчить иллюстрацию, а не ограничить возможные варианты реализации описания настоящей заявки. Более конкретно, фиг. 1 показывает примеры, в которых клиентская система 104a является переносной вычислительной системой, которая может быть охарактеризована как компактный переносной компьютер, портативный компьютер или другая мобильная система. Клиентская система 104n представляет стационарную или настольную систему. Однако настоящее описание также предусматривает другие формы клиентских систем, включая, но не ограничиваясь этим, беспроводные персональные цифровые помощники, интеллектуальные телефоны (смартфоны) или подобное.

Обращаясь к серверам 102 более подробно, серверы могут включать в себя один или более процессоров 110, которые могут быть конкретного типа или иметь конкретную архитектуру, выбранных в качестве подходящих для конкретных вариантов реализации. Процессоры 110 могут присоединяться к одной или более системам 112 шин, которые выбраны для совместимости с процессорами 110.

Серверы 102 могут включать в себя один или более экземпляров считываемых компьютером носителей 114 данных, которые присоединяются к системам 112 шин. Системы шин могут обеспечивать возможность процессорам 110 считывать код и/или данные на/со считываемых компьютером носителей 114 данных. Носители 114 могут представлять собой элементы хранения, реализуемые с помощью любой подходящей технологии, в том числе, но не ограничиваясь этим, полупроводников, магнитных материалов, оптики или т.п. Носители 114 могут включать в себя компоненты памяти, которые могут быть классифицированы как RAM, ROM, флэш-память либо другие типы, и также могут представлять собой жесткие диски.

Носители 114 данных могут включать в себя один или более модулей 116 инструкций, которые при их загрузке в процессор 110 и исполнении предписывают серверу 102 обеспечивать некоторый набор служб клиентским системам, которые обеспечивают возможность при совместной работе множественных клиентов осуществлять доступ и обновлять структурированные элементы данных. Как подробно изложено по всему этому описанию, эти серверные службы совместной работы могут обеспечивать возможность одному или более пользователям (показанным на последующих чертежах) на клиентских системах осуществлять доступ к структурированным данным, хранящимся в пределах основной таблицы 118. Это описание обеспечивает примеры, касающиеся структурных данных в контексте приложений электронной таблицы, но принципы, описанные в данной заявке, могут распространяться на другие приложения, не отклоняясь от объема и сущности настоящего описания. Вообще модули 116 служб совместной работы управляют доступом и переносом данных к и от основной таблицы 118, как обозначено пунктирной линией 120.

Обращаясь к клиентским системам 104 более подробно, клиентские системы могут включать в себя один или более процессоров 122. Эти процессоры могут быть выбраны в качестве подходящих для клиентских систем и могут быть одного и того же или разного типа, либо имеют одинаковую или разную архитектуры по отношению к процессорам 110 в серверах. Процессоры 122 могут присоединяться к одной или более системам 124 шин, которые выбраны для совместимости с процессорами 122, и таким образом могут быть одного и того же или разного типа либо одинаковой или разной архитектуры по отношению к системам 112 шин в серверах.

Клиентские системы могут включать в себя один или более экземпляров компьютером считываемых носителей 126 данных, которые присоединяются к системам 124 шин. Системы 124 шин могут позволять процессорам 122 считывать код и/или данные на/со считываемых компьютером носителей 126 данных. Общие описания носителей 114 данных, в общем, применимы к носителям 126 хранения, и таким образом здесь не повторены.

Носители 126 данных могут включать в себя один или более модулей 128 инструкций, которые при их загрузке в процессор 122 и исполнении, предписывают клиентским системам 102 взаимодействовать с серверными модулями 116, чтобы обеспечить службы совместной работы. Как подробно изложено по всему этому описанию, эти клиентские совместные службы могут обеспечивать возможность пользователям клиентских систем загружать структурированные данные из основной таблицы 118 в клиентскую, или локальную, таблицу 130. В общем модули 128 совместных служб управляют доступом и переносами данных к и от клиентской таблицы 130, как обозначено пунктирной линией 132.

Как проиллюстрировано на фиг. 1, серверные службы 116 и клиентские службы 128 могут взаимодействовать для обеспечения возможности потокам последовательностей выполняемых операций проходить между серверами и клиентскими системами, как в общем представлено пунктирной линией 134. Последующие чертежи и описание дополнительно конкретизируют потоки 134 выполняемых операций совместной работы, но эти потоки выполняемых операций в целом представляют потоки команд, потоки данных и другую обработку, отнесенные к клиентским системам 104 (и связанным с ними пользователям), совместно работающим по структурированным данным, размещенным на серверах 102.

Несмотря на то, что фиг. 1 конкретизирует компоненты сервера 102n и клиентской системы 104n, эти описания в равной степени могут применяться к серверам 102a и клиентской системе 104a. Эти описания могут также относиться к серверам или клиентским системам, которые не показаны на фиг. 1, но могут быть включены в варианты реализации обеспеченных здесь технологий.

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

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

Фиг. 2 переносит примеры клиентских таблиц 130, с примерной клиентской таблицей 130a, ассоциированной с клиентской системой 104a, с фиг. 1, и примерной клиентской таблицей 130n, ассоциированной с клиентской системой 104n. Фиг. 2 также переносит примерную основную таблицу 118, ассоциированную с сервером 102. Соответствующие экземпляры клиентских совместных служб 128a и 128n управляют клиентскими таблицами 130a и 130n, и серверные совместные службы 116 управляют основной таблицей 118. Фиг. 2 также предоставляет экземпляры потоков 134 последовательностей выполняемых операций совместной работы, при этом потоки 134а выполняемых операций переходят к/от клиентской совместной службы 128a и потоки 134n выполняемых операций переходят к/от клиентской совместной службы 128n. При просмотре фиг. 2 становится понятно, что различные потоки данных, которые показаны на фиг. 2, дополнительно конкретизируют потоки 134a и 134n выполняемых операций совместной работы.

Обращаясь к процессу и потокам 200 данных более подробно, блок 202 представляет клиентскую систему (например, клиентскую систему 104n, связанную с клиентской службой 128n), представляющую пользовательской интерфейс (UI), который позволяет пользователю осуществлять запрос, чтобы один или более структурированных элементов данных были опубликованы с клиентской системы на сервер. Примеры таких структурированных элементов данных могут включать в себя таблицы, которые представляют наборы структур данных, размещенных в строках и столбцах, с ячейками, определенными в их пересечениях. Эти ячейки могут содержать данные, формулы или метки, как выбрано или запрограммировано пользователями. Блок 202 может включать в себя представление UI в ответ на явную команду пользователя или может включать в себя представление пользовательского интерфейса (UI) автоматически в ответ на некоторый набор условий.

В ответ на UI, представленный в блоке 202, пользователь 204 может выбрать одну или более таблиц для публикации. Например, пользователь, возможно, запрограммировал множество различных таблиц или рабочих листов, чтобы выполнить различные функции, и может выбрать один или более из этих таблиц или рабочих листов для публикации, чтобы обеспечить возможность другим пользователям сотрудничать при работе с этими таблицами или рабочими листами. Пользователь может решить опубликовать множественные таблицы вне той же самой рабочей книги. Пользователь может выбрать все таблицы или рабочие листы для публикации либо может выбрать части их. Фиг. 2 показывает такие выборы таблицы позицией 206, и блок 208 обработки представляет прием этих выборов 206. Например, блок 208 может включать в себя прием индикаций щелчков мыши, выборов или других ответов от пользователя, что представлено в соответствующих сигналах и/или событиях, как передано аппаратными средствами и/или программным обеспечением.

Блок 210 представляет посылку или передачу таблиц, которые пользователь выбрал для публикации. Фиг. 2 показывает эти выбранные таблицы позицией 212. Несмотря на то, что явно не указано на фиг. 2, блоки 202, 208 и 210 могут быть повторены любое число раз, чтобы обеспечить возможность пользователям выбрать множественные экземпляры структурированных данных для публикации другим пользователям.

На сервере, связанном с серверной службой 116, блок 214 представляет посылку одной или более клиентским системам уведомлений, что таблицы (например, 212) были опубликованы и являются доступными для потребления. Без ограничения возможных вариантов реализации, термин «публикация», как используется здесь, может относиться к размещению таблицы в общий пул или библиотеку, где любое число других клиентов (и/или соответствующих пользователей) может просмотреть эти опубликованные таблицы и выбрать одну или более из этих таблиц для совместной работы. В вариантах реализации этот пул или библиотека опубликованных таблиц могут быть открытыми, в том смысле, что неопределенное число клиентов или пользователей может обратиться к библиотеке и получить совместно используемые копии таблиц для реализации совместной работы. Когда некоторый клиент публикует таблицу, этот клиент может не знать, какие другие клиенты, в конечном счете, совместно используют опубликованную таблицу.

Фиг. 2 обозначает уведомления о доступных таблицах позицией 216, и эти таблицы 216 могут включать в себя таблицы 212 в том виде, как опубликовано клиентскими службами 128n, а также другие таблицы, опубликованные другими клиентскими службами и связанными с ними клиентскими системами. Доступные таблицы 216 могут быть организованы в библиотеку, которая может содержать записи для разнообразных таблиц, которые были опубликованы.

Серверные системы и клиентские системы могут определять один или более протоколов, которые организуют набор подходящих элементов данных (например, таблицы, информационные структуры совместной работы или любые их части, как показано в примерной иерархической структуре, приведенной выше), которые являются доступными для выбора клиентскими системами. Эти протоколы могут идентифицировать, какие из этих подходящих элементов данных были выбраны конкретными клиентскими системами. Например, эти протоколы могут организовать подходящие элементы данных и могут связывать уникальный идентификатор с соответствующими из подходящих элементов данных. Для простоты ссылки, но не для ограничения возможных вариантов реализации, это описание относится к соответствующим уникальным идентификаторам точек данных, которые связаны с этими подходящими элементами данных. Таким образом, блок 214 может включать в себя связывание соответствующих экземпляров этих идентификаторов с элементами в пределах доступных таблиц 216, которые публикуются от серверных систем для клиентских систем. Службы 128 и 116 совместной работы поддерживают эти идентификаторы скрыто от пользователей, пока пользователи явно не захотят увидеть идентификаторы. Кроме того, службы 128n совместной работы, связанные с публикующим или выкладывающим клиентом, могут принимать идентификаторы, связанными с этими таблицами, опубликованными или выложенными конкретным клиентом, чтобы облегчить последующее отслеживание и согласование изменений в отношении этих опубликованных или выложенных таблиц.

На другой клиентской системе (например, 104a), связанной с клиентской службой 128a, блок 218 изображает представление UI, который предоставляет таблицы, рабочие книги или другие структурированные элементы данных, которые были опубликованы другими клиентами и, таким образом, являются доступными для потребления клиентской системой 104a. Пользователь 220, связанный с клиентской системой 104a, может осуществлять просмотр UI и выбрать один или более доступных структурированных элементов данных, представленных на UI. Фиг. 2 обозначает эти выборы позицией 222.

В свою очередь, блок 224 представляет модуль 128a клиентских служб, принимающий выборы структурированных элементов данных (например, таблицы, рабочие листы, строки, столбцы или другие конструкции таких структурированных элементов данных) от пользователя. Например, блок 224 (подобно вышеупомянутому блоку 208) может включать в себя прием индикаций щелчков мыши, выборов или других реакций от пользователя, что представлено в соответствующих сигналах и/или событиях, как передано аппаратными средствами и/или программным обеспечением.

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

На серверных системах, которые поддерживают основные таблицы 118, блок 230 представляет прием выборов 228 от клиентских систем. Как отмечено выше, выборы 228 могут сослаться на один или более идентификаторов, соответствующих выбранным элементам данных. В свою очередь, блок 232 представляет извлечение выбранных элементов данных из основной таблицы (например, 118). Блок 232 может включать в себя использование входных идентификаторов, включенных в выборы 228 в виде индексов в основную таблицу. Блок 234 представляет посылку выбранных элементов данных на клиентскую систему, которая запросила эти элементы данных. Фигура 2 обозначает эти переданные элементы данных позицией 236.

На клиентских системах блок 238 представляет прием затребованных элементов данных, которые пользователь ранее выбрал (то есть, выборы 222). Фиг. 2 иллюстрирует пример, в котором клиентская таблица 130a принимает элементы данных, опубликованные от другой клиентской таблицы 130n. Однако следует отметить, что любое число клиентских таблиц может запрашивать и принимать элементы данных, опубликованные от этой клиентской таблицы 130n, как теперь проиллюстрировано на фиг. 3. Кроме того, любое число клиентских таблиц может публиковать элементы данных для осуществления совместной работы с другими пользователями.

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

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

Как показано на фиг. 3, клиентская таблица 130a переносится с фиг. 2. Фиг. 3 также обеспечивает другую клиентскую таблицу 130m, поддерживаемую другой клиентской системой, предполагая, что эта другая клиентская система также запрашивала и принимала один или более элементов данных от серверной системы. Фиг. 3 иллюстрирует клиентские совместные службы 128m, которые поддерживают клиентскую таблицу 130m. Элементы данных, принятые клиентской таблицей 130m, могут быть или могут не быть такими же как те, которые затребованы и приняты клиентской таблицей 130a.

Обращаясь к клиентской таблице 130a, обработка с фиг. 2 может перейти к блоку 302, который представляет объединение элементов данных, принятых от основной таблицы, с локальной клиентской таблицей 130a. Например, клиентская таблица 130a может поддерживать некоторые данные, которые являются частными или локальными для пользователя, связанного с клиентской таблицей 130a, и может запрашивать некоторые элементы опубликованных элементов данных для дополнения локальных или частных данных. Блок 302 может, таким образом, включать в себя интеграцию опубликованных элементов данных (например, 236 на фиг. 2), что приняты от серверных систем, в любую локальную/частную информацию, запомненную в клиентской таблице 130a. Блок 302 может также включать в себя поддержание любой информации идентификаторов или индексов, принятой с опубликованными элементами данных, после интеграции этих элементов данных в клиентскую таблицу 130a. Как описано дополнительно ниже, информация идентификаторов или индексов может обеспечивать возможность осуществлять отслеживание изменений, произведенных локально в пределах клиентской таблицы 130a, и может обеспечивать возможность предоставления отчетов об этих изменениях назад серверным системам и распространения этих изменений по множественным системам совместно работающих клиентов.

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

Блок 306 изображает представление локальной таблицы пользователю 220, применив любое локально заданное форматирование, фильтры, сортировки или другие операции к локальной таблице и выполнив интеграцию любых элементов основных данных, принятых от серверных систем. Блок 306 может включать в себя выделение или иную индикацию элементов основных данных, так чтобы локальный пользователь 220 мог без труда понимать, какие данные являются локальными и какие данные являются внешними (то есть теми, что происходят от серверных систем или других клиентских систем). Фиг. 3 обозначает позицией 308 локальную таблицу, представляемую пользователю 220, в ответ на локальные спецификации 310 (например, форматирование, сортировку, фильтрацию или подобные настройки).

Обращаясь к другой принимающей клиентской таблице 130m и связанным службам 128m совместной работы, блоки 312, 314 и 316 соответствуют обработке, описанной в блоках 302, 304 и 306, как выполнено для другой локальной клиентской таблицы 130m. В частности, блок 314 может включать в себя форматирование, сортировку, фильтрацию или иную локальную настройку локальной клиентской таблицы 130m в ответ на локальные спецификации или команды 318, заданные пользователем 320. Фиг. 3 обозначает позицией 322 локальную таблицу, представляемую пользователю 320. Однако локальные спецификации 310 для локальной клиентской таблицы 130a могут отличаться от локальных спецификаций 318 для локальной клиентской таблицы 130m. В этом случае клиентские системы (более конкретно, службы 128a и 128m) могут обеспечивать возможность различным пользователям 220 и 320 настроить свои локальные таблицы 130a и 130m по-другому согласно их собственным спецификациям. Например, пользователи 220 и 230 могут сортировать или фильтровать свои локальные таблицы 130a и 130m по-разному.

Как показано пунктирными линиями 324 и 326, локальные таблицы 130a и 130m могут включать в себя, по меньшей мере, некоторые элементы основных данных, которые приняты от серверной системы, с элементами основных данных, интегрируемыми в локальные таблицы. Идентификаторы могут служить для идентификации и организации элементов основных данных в пределах локальных таблиц. Для простоты иллюстрации, но не ограничивая возможные варианты реализации, описание процесса и потоков 300 данных продолжено на фиг. 4, как указано показанной на фиг. 3 ссылкой за пределы страницы.

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

Начиная со ссылки за пределы страницы с фиг. 3, блок 402 представляет прием одной или более команд от пользователя (например, пользователя 220). В целом эти команды могут представлять любые обновления для клиентской таблицы 130a, направленные либо на локальные или частные данные, либо на основные данные, принятые от серверных систем. Фиг. 4 обозначает эти команды в общем позицией 404.

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

В серверной системе блок 410 представляет прием обновлений 408 по отношению к основной таблице. В свою очередь, блок 412 представляет объединение этих обновлений, принятых от клиентских систем, с основной таблицей. Блок 412 может включать в себя извлечение идентификаторов из обновлений 408, осуществление доступа к части основной таблицы (например, 118), которая соответствует указанным идентификаторам, и обновление соответствующих частей основной таблицы.

Обращаясь к компоненту 128m совместных служб, этот компонент служб может предоставлять возможность другому пользователю (например, 320) обновлять клиентскую таблицу (например, 130m на фиг. 3), которая управляется этим компонентом 128m. Более конкретно блок 414 представляет прием команд обновления от пользователя 320, обозначенных на фиг. 4 позицией 416. В ответ на команды 416 компонент 128m служб может обновлять клиентскую таблицу соответственно. Как обсуждалось выше применительно к блоку 402, эти обновления могут включать в себя обновления по отношению к локальным/частным данным, а также обновления основных данных, содержащихся в клиентской таблице. В случаях, когда пользовательские команды приводят к изменениям элементов основных данных, блок 418 представляет посылку любых таких обновлений серверной системе, с которой связаны элементы основных данных. Фиг. 4 обозначает эти обновления позицией 420.

Возвращаясь к серверным службам 116 совместной работы, блок 410 (описанный выше) может включать в себя прием обновлений не только от компонента 128a клиентских служб, но также и от компонента 128m клиентских служб. Иными словами, блок 410 может включать в себя прием обновлений 408 и/или обновлений 420, а также обновлений от других клиентов, не показанных на фиг. 4. Кроме того, блок 412 может включать в себя интеграцию или объединение этих обновлений в основную таблицу, поддерживаемую серверной системой. Идентификаторы могут облегчить эту интеграцию или объединение путем определения того, какие части основных данных были изменены клиентскими системами. Собранные по всем клиентским системам, эти идентификаторы указывали бы, какие части основных данных подлежат обновлению и повторной публикации для клиентов.

Блок 422 представляет публикацию обновлений для основной таблицы по различным клиентам. Более конкретно, предполагая, что компонент 128m клиентских служб изменил некоторые основные данные, связанные с серверной системой, блок 422 может включать в себя публикацию этих изменений или обновлений к компоненту 128a клиентских служб. Блок 422 может также включать в себя публикацию этих изменений для любых других клиентских систем, которые подписались на эти основные данные. В контексте HTTP (протокола передачи гипертекстовых файлов) блок 422 может включать в себя серверные службы, реагирующие на опрос от клиентов.

Подобным образом, если компонент 128a клиентских служб выполнил изменения в некоторых основных данных, которые связаны с серверной системой, тогда блок 422 может включать в себя публикацию этих изменений для компонента 128m клиентских служб и любых других клиентских систем, которые подписались на эти основные данные. Фиг. 4 обозначает позицией 424 обновления основной таблицы, которые публикуются для компонента 128a клиентских служб, и позицией 426 обозначает обновления основной таблицы, которые публикуются для компонента 128m клиентских служб. Эти обновления могут ссылаться на идентификаторы основных таблиц, которые находятся под влиянием со стороны конкретных изменений.

В компоненте 128a клиентских служб блок 428 изображает прием обновлений 424 таблицы, которые указывают изменения, выполненные другими клиентскими системами, в данных основной таблицы. В свою очередь, блок 430 представляет объединение этих обновлений в локальную клиентскую таблицу (например, 130a на фиг. 3). Параметр идентификатора может содействовать блоку 430 путем предоставления возможности компоненту 128a клиентских служб определять, какие части данных основной таблицы следует обновить. Блок 432 изображает представление обновленных данных основной таблицы пользователю 220. Блок 432 может включать в себя представление обновленных данных основной таблицы наряду с любыми локальными или частными данными, поддерживаемых клиентской системой.

Обращаясь к другому компоненту 128m клиентских служб, блоки 434, 436 и 438 соответствуют, в общем, блокам 428, 430 и 432. Таким образом, блок 434 представляет прием обновлений 426 основной таблицы, блок 436 представляет объединение этих обновлений в локальное визуальное отображение данных на клиентской системе и блок 438 изображает представление этих объединенных обновлений пользователю клиентской системы.

На обеих клиентских системах компоненты 128a и 128m клиентских служб могут неограниченно повторять блоки, показанные на фиг. 4, поскольку пользователи 220 и 320 продолжают взаимодействовать с элементами данных, представленными им. Таким образом, компонент 128a клиентских служб может повторять блоки 402, 406, 428, 430 и 432 любое число раз, как обозначено стрелкой 440. Подобным образом, компонент 128m клиентских служб может повторить блоки 414, 418, 434, 436 и 438 любое число раз, как обозначено стрелкой 442.

Согласно вышеприведенному способу системы множественных клиентов могут совместно осуществлять доступ к совместно используемым элементам данных (например, таблицам в электронной таблице). В некоторых случаях множественные клиенты могут осуществлять доступ к этим совместно используемым элементам данных одновременно. В других случаях некоторые клиенты могут пребывать в режиме офлайн, при этом любые изменения, выполненные в состоянии офлайн, согласовываются в следующий раз, когда клиент переходит в состояние онлайн. Обновления могут происходить одновременно, в последовательности друг за другом или асинхронно друг с другом. Любой из этих клиентов может обновлять эти совместно используемые элементы данных, при этом обновления, выполненные одним клиентом, распространяются любым другим клиентам, совместно использующим те же самые элементы данных. Серверная система может объединять и согласовывать эти обновления или изменения, используя идентификаторы, назначенные совместно используемым элементам данных. Описав потоки 200, 300 и 400 процесса на фиг. 2-4, обсуждение теперь переходит к описанию рабочих примеров вышеописанных методик для обеспечения возможности при совместной работе множественных клиентов осуществлять доступ и обновлять структурированные элементы данных, что представляется сейчас вместе с фиг. 5-7.

Фиг. 5 иллюстрирует примеры, обозначенные в общем позицией 500, структуры основной таблицы, разделенной между двумя или более структурами клиентских таблиц. Для простоты иллюстрации, но не ограничивая возможные варианты реализации, фиг. 5-7 могут переносить ссылочные позиции с предыдущих чертежей, чтобы ссылаться на подобные элементы. Например, компонент 128a клиентских служб может управлять клиентской таблицей 130a, компонент 116 основных служб может управлять основной таблицей 118 и компонент 128m клиентских служб может управлять клиентской таблицей 130m. Для простоты ссылки и описания, фиг. 5 иллюстрирует фиктивного пользователя по имени «Стив», осуществляющего доступ к клиентской таблице 130a через компонент 128a совместных служб, и фиктивного пользователя по имени «Мириам», осуществляющего доступ к клиентской таблице 130m через компонент 128m совместных служб. С целью описать примеры, показанные на фиг. 5-7, но не ограничить возможные варианты реализации, предполагается, что Стив и Мириам используют приложения типа электронной таблицы, такие как семейство приложений EXCEL®, доступных от Корпорации Microsoft, Редмонд, Вашингтон. Предоставляя данные примеры, описание настоящей заявки не ограничивается этими конкретными продуктами или их версиями, и может быть реализовано во множестве продуктов и/или версий, доступных от любых конкретных поставщиков.

Фиг. 5 обеспечивает пример основной таблицы 118, названной «LiveTable», которая содержит рабочую книгу Master.Xlsx 502, прогоняющуюся на сервере (например, 102 на фиг. 1). LiveTable 118 может включать в себя вычисленный (то есть, «Calc») столбец 504, который выполняет некоторые вычисления на основе остальной части рабочей книги. Как описано в примерах ниже, столбец calc может содержать формулы, которые вычисляют значения, основанные на данных, постоянно находящихся на сервере, и/или данных, обеспеченных совместно работающими пользователями, такими как Стив, Мириам и др. Предполагая, что рабочей книге 502 задается конфигурация для отслеживания и управления товарно-материальных запасов, рабочая книга может обеспечивать информацию, относящуюся к первому элементу в строке 506, и может предоставлять информацию, касающуюся второго элемента в строке 508. Столбец 510 может обеспечивать некоторое число или количество таких элементов, столбец 512 может указывать, где эти элементы расположены, и столбец 514 может именовать эти элементы. Ячейки, определяемые пересечениями этих строк и столбцов, обеспечивают описание конкретных экземпляров информации, перемещенной строками и столбцами.

Обращаясь к клиентской таблице 130a, предполагая, что пользователь Стив является администратором, он открыл рабочую книгу 516, названную «Admin lnventory.xls», и импортировал в клиентскую таблицу 130a, по меньшей мере, часть LiveTable, наряду с инструкциями на изменение данных, потребляемых из этой LiveTable. Предположим, например, что Стив принял текущие экземпляры значений в строках 506 и 508 от основной таблицы. Фиг. 5 обозначает эти импортированные строки позициями 506a и 508а, как используется в пределах клиентской таблицы 130a. Предположим также, что Стив импортировал столбец 504 calc из основной таблицы, как обозначено позицией 504a. Клиентская таблица 130a содержит вычисленное значение 300 для объекта «Foo» («нечто»), и вычисленное значение 2000 для объекта «Bar» («бар»), как показано в столбце 504a. Вообще, столбцы в рабочей книге 516 упорядочены согласно столбцам в рабочей книге 502.

Обращаясь к клиентской таблице 130m, предполагая, что пользователь Мириам является аналитиком, она открывает рабочую книгу 518, названную «Inventory Anaysis.xls». Эта рабочая книга 518 может содержать, по меньшей мере, части LiveTable, при этом строки 506m и 508m соответствуют строкам 506 и 508 из основной таблицы 118, и столбцы рабочей книги 518 в целом упорядочиваются согласно столбцам в рабочей книге 502. Рабочая книга 518 включает в себя и включила строку 520, помеченную «Итоговая сумма». Строка 520 суммирует вычисленные значения из calc столбца 504m, который соответствует calc столбцу 504 в рабочей книге 502. Рабочая книга 518 Мириам может также включать в себя строку 522, которая суммирует число элементов «Bar», как сообщено Мириам, Стивом и любыми другими пользователями, которые пользуются данными из основной таблицы 118. Ячейка 524 может определять формулу суммирования, используемую для подсчета элементов «Bar». Описав начальные структуры рабочих книг 502, 516 и 518, обсуждение теперь переходит к описанию того, каким образом обрабатываются изменения в совместно используемой информации, представленное сейчас совместно с фиг. 6 и 7.

Фиг. 6 иллюстрирует обновления, обозначенные, в общем, позицией 600, которые могут возникать, когда один совместно работающий пользователь обновляет данные, которые потребляются из основной таблицы. В этих примерах пользователь Стив добавляет новую строку 602 к его рабочей книге 516 (перенесенной с фиг. 5). Эта новая строка 602 обеспечивает дополнительные данные для элементов «Bar», указывая, что 20 из этих элементов являются доступными в местоположении «Редмонд». Это обновление рабочей книги 516 обеспечивает пример потоков 408 данных, проиллюстрированных на фиг. 4, посредством чего клиентская система обновляет информацию из основной таблицы. Таким образом, фиг. 6 перенесла ссылочную позицию 408, чтобы пометить обновления для основной таблицы, возникающие в результате локальных изменений, в этом случае изменения в отношении строк и ячеек.

В основной таблице 118 модуль 116 совместных служб принимает обновления 408. В ответ рабочая книга 502 добавляет новую строку 602n и связывает ее со значением, чтобы идентифицировать эту новую строку (например, row_id) в пределах структурированных элементов данных, разделяемых между различными клиентскими системами для совместной работы. Рабочая книга 502 также обновляет столбцы 510, 512, 514 и 504 для новой строки 602n, чтобы внедрить обновления 408. Таким образом, основная таблица сейчас указывает, что 20 экземпляров из электронного объекта «Bar» являются доступными в Редмонде. Кроме того, ячейка 604 в пределах строки 602n включает в себя новый экземпляр формулы, определенной в пределах примерного столбца 504 calc. Описав, каким образом основная таблица и связанная с ней рабочая книга 502 могут изменяться для внедрения изменений от клиентской рабочей книги 516 Стива, обсуждение теперь переходит к описанию того, каким образом эти изменения могут быть распространены на рабочие книги Стива и Мириам.

Фиг. 7 иллюстрирует обновления, обозначенные, в общем, позицией 700, которые распространяются от основной таблицы из-за обновлений от одной из клиентских таблиц. Продолжая вышеупомянутый пример, показывающий локальные таблицы Стива и Мириам, основная таблица 118 и основной рабочий лист 502 могут сообщать об изменениях строки/ячейки рабочему листу 518 Мириам, которые возникли в результате изменений, выполненных в отношении рабочего листа 516 Стива. Фиг. 7 обозначает эти обновления в отношении рабочего листа Мириам как изменения 702 строки/ячейки. Таким образом, служба 128m совместной работы обновляет рабочий лист 518 Мириам новой строкой 602m, которая соответствует строкам 602 и 602n, присутствующим в других рабочих листах. Более подробно, идентификатор (например, параметр row_id) может связывать или привязывать новую строку 602m Мириам к соответствующей строке 602n в основной таблице и к соответствующей строке 602 в рабочем листе Стива. В этом случае рабочий лист Мириам обновляется для того, чтобы отразить 20 элементов «Bar» в Редмонде.

В дополнение к обновлению Мириам новыми строками/ячейками, основной рабочий лист 502 также повторно вычисляет столбец 504 calc в ответ на изменения Стива и обновляет таблицы Стива и Мириам и рабочие листы повторно вычисленными значениями. Фиг. 7 обозначает позицией 704 обновления столбца calc, как передано рабочему листу 516 Стива, и обозначает в 706 обновления столбца calc, как передано рабочему листу 518 Мириам. Обновления 702, 704 и 706 обеспечивают, примеры обновлений 424 и 426 основной таблицы, показанных на фиг. 4. Однако фиг. 7 рассматривает эти обновления с новыми числами, чтобы обеспечить отдельное обсуждение различных типов обновлений для различных клиентских таблиц.

На рабочем листе 516 Стива, в ответ на обновление 704, совместная служба 128a обновляет столбец 504a calc так, чтобы ячейка 708a содержала значение calc, вычисленное формулой в ячейке 604 основной таблицы. В показанном примере ячейка 708a содержит значение '8000'. На рабочем листе 518 Мириам, в ответ на обновления 702 и 704, совместная служба 128m обновляет столбец 504m calc так, чтобы ячейка 708m содержала значение calc (например, '8000'), вычисленное ячейкой 604 основной таблицы. Поскольку столбец calc теперь содержит новое значение (то есть, значение '8000' в 708m), строка 520 Мириам обновляется локально, как обозначено обновленной суммой '10300' в ячейке 710.

Напомним из описания относительно фиг. 5, что таблица Мириам включает в себя строку 522 для суммирования вычисленных значений, которые являются приписываемыми к элементам, помеченным «Bar». В ответ на значение '8000' в новой ячейке 708m ячейка 524 суммирует это значение с ранее существующим значением '2000' в ячейке 712, приводя в результате к обновленному итоговому значению '10000'. Описав вышеупомянутые примеры изменений строки и ячейки, распространяющихся по множественным совместно работающим клиентам, описание теперь предоставляет более подробные примеры различных типов изменений.

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

Когда клиентская таблица вставляет или добавляет новую строку в конец таблицы, клиентская таблица может генерировать временный row_id для новой строки. Затем клиентская таблица может послать уведомление о добавляемой строке на сервер, ссылаясь на временный row_id. Сервер может генерировать и возвращать постоянные row_id, которые клиентская таблица (и другие сервер или клиентские таблицы) затем использовала бы для новой строки. Основная таблица и другие клиентские таблицы, связанные с ней, затем добавили бы новую строку к их таблицам с постоянными row_id. Местоположение новой строки в пределах таблицы может быть передано или может быть не передано. Как правило, новая строка может появляться внизу каждой таблицы, возможно и сверху, если пользователь одновременно добавляет новую строку. В некоторых вариантах реализации уведомление о новой строке может удерживаться на клиенте, пока некоторые данные не будут доступными для посылки с ним на сервер.

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

Клиентские службы могут обеспечивать функцию фильтрации, которая может выступать в роли сортировки. Функция фильтрации может быть выполнена в ответ на локальные спецификации у конкретных клиентов (например, 310 и 318 на фиг. 3). Различные пользователи могут задавать свои собственные фильтры, не оказывая влияния на других пользователей. Подобные сортировки, фильтры могут быть приспособлены не вызывать постоянного изменения местоположения данных по мере того как пользователь вводит данные. Опция выполнения фильтрации в любом случае может иметь значение, подобное опции выполнения сортировки в любом случае.

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

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

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

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

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

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

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

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

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

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

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

• Условные форматы, оцененные по основным таблицам, могут быть распространены на потребляющие клиентские таблицы как уровень приоритета выше статического основного форматирования.

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

• Основная таблица может посылать форматирование вниз в клиентские таблицы. В некоторых случаях это форматирование может быть условным форматированием. В некоторых случаях конкретный клиент может определить локальные спецификации (например, 310 и 318 на фиг. 3) для форматирования на этом клиенте. В этих примерах модуль совместных служб (например, 128) на этом клиенте может согласовывать форматирование, посылаемое вниз от основной таблицы, с форматированием, определенным локальными спецификациями на клиенте.

Отслеживание, основанное на уникальных идентификаторах (например, row_id) в пределах клиентской таблицы может поддерживаться, в то время как пользователь находится в режиме офлайн. Позже, когда пользователь переходит в режим онлайн, отслеживание может согласовываться с изменениями, которые с того момента произошли в основной таблице.

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

• Удаление столбца;

• Добавление столбца; или

• Изменение вычисления вычисленного столбца, или подобное.

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

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

Инструментальные средства и методики, описанные в данной заявке, могут функционировать наряду с основанной на портале совместной работой и платформами управления документооборотом, такими как платформа SHAREPOINT™, доступная от Microsoft, или конкурирующие платформы. Например, Списки (Lists) в технологиях SHAREPOINT™ позволяют осуществлять сохранение и редактирование данных и являются пригодными для использования вне приложений электронной таблицы. В некоторых случаях эти платформы могут обеспечивать возможность инструментальным средствам и методикам экспонировать интерфейсы API базы данных по основной таблице, чтобы позволить использование этих API другим технологиям. В некоторых случаях Список может быть связан с основной таблицей, при этом Список является обновляемым, когда основная таблица повергается изменениям. Благодаря этой особенности, Список принимает обновления, когда основная таблица обновляется, или основная таблица может принять обновления от Списка, когда Список изменяется. Конфликты могут обрабатываться с помощью UI, в некоторых случаях, или при помощи характерной пометки строк.

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

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