JP2023533122A - ユーザ向けのスプレッドシートプログラミング言語 - Google Patents

Abstract

スプレッドシート及びスプレッドシートをプログラミングするための方法が提供される。一態様によれば、スプレッドシートは、二次元アレイに配置された複数のセルを含む。複数のセルのうちの１つ以上は、変数の複数の値に対応するデータのための複数の隣接する変数値セルを含む。複数の隣接する変数値セルは、複数の隣接する変数値セルのセル範囲の開始と終了を示すセル値のペアによってユーザ定義される。また、複数のセルは、変数の複数の値によって定義される変数範囲を含む式に応答して、その中に定義された式を有するセルからデータが流入することができるスピルエリアを含む。スピルエリアは、変数の複数の値に対応する複数の表現ソリューションに自動的にサイズ調整される。【選択図】図１

Description

（優先権の主張）
本出願は、２０２０年５月２９日に出願されたシンガポール特許出願第一０２０２００５０９１Ｒ号からの優先権を主張する。

本発明は、一般に、コンピュータのスプレッドシートシステムに関し、より具体的には、ユーザ向けのスプレッドシートプログラミング言語のための方法及びシステムに関する。

Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｐｙｔｈｏｎ（登録商標）等、プロのプログラマによって使用される現在の主流言語の多くは、プレーンテキストの線形フローに基づいている。これらの言語の中心的な目標は、機能性がゼロから構築されるのではなく、むしろ既存のライブラリ（通常は関数とクラス（ｃｌａｓｓ）の形で）から組み立てられるレゴ（登録商標）のような方法でアプリケーション構築を可能にすることである。異なるライブラリを共存して、連携させることができ、プログラマの主な仕事は、これらのロジックブロックをカスタマイズし、オーケストレーションするだけである。今日の言語は、非常に用途が広いことが判明しており、この目標をほぼ達成している。しかしながら、残念なことに、大多数の非プログラマにとっては抽象的すぎることが判明し、プログラマと非プログラマの間に大きな乖離が生じ、非プログラマが単なる技術の受動的消費者に成り下がっている。

キャズム（ｃｈａｓｍ）の反対側にはスプレッドシートがあり、これはプレーンテキストではなく、二次元（２Ｄ）グリッド構造に基づいている。Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）やＧｏｏｇｌｅ（登録商標）Ｓｈｅｅｔのようなスプレッドシートシステムは、実用的にアクセス可能な唯一のシステムの一部であり、そこで、非プログラマのユーザがコンピュータによる実行のために自明ではないロジックを表現できる。しかしながら、開発環境として見た場合、関数とクラスの形でコードを再利用する機能、ユニットテスト機能、第三者スプレッドシートのインポート機能等、主流のプログラミング言語で必須と見なされる基本的な機能がスプレッドシートには備わっていない。そのため、実際のスプレッドシートは、大量の重複コード及びバグが見つかることが多く、要件が複雑になると、すぐにスプレッドシートが管理できなくなる環境に陥ってしまう。さらに、スプレッドシートからより技術的に健全なソリューションへのアップグレードパスがない。ユーザは、より複雑な機能を構築するためにＶＢＡ（Ｖｉｓｕａｌ Ｂａｓｉｃｓ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓ）プログラマに頼る（ここでは、ＶＢＡが従来のプレーンテキストベースの言語である）か、非常に頻繁に、単にスプレッドシートを捨て、主流な言語でロジックを完全に再実装している。

したがって、従来のスプレッドシート対応プログラミングの欠点を克服し、簡単で融通の利く多用途で下位互換性のあるスプレッドシートに適したソリューションを提供する、堅牢なユーザ向けスプレッドシートプログラミング言語が必要とされている。さらに、他の望ましい特徴及び特性は、添付の図面及び本開示の背景と合わせて考慮される、以下の詳細な説明及び添付の特許請求の範囲から明らかになるであろう。

本実施形態の少なくとも１つの態様によれば、スプレッドシートプログラミングするための方法が提供される。本方法は、スプレッドシートのセルにラベルを割り当てるステップを含み、前記ラベルのそれぞれは、変数の複数の値に対応するデータのための複数の隣接する変数値セルのうちの１つに割り当てられる。前記複数の隣接する変数値セルは、複数の隣接する変数値セルのセル範囲の開始及び終了を示すラベルのペアによってユーザ定義される。本方法は、定義された式を有するセルから、変数の複数の値によって定義される変数範囲を含む式に応答して、データが流れ込むことができるスピルエリアを定義するステップさらに含む。前記スピルエリアは、前記変数の複数の値に対応する複数の式解に自動的にサイズ調整される。

本実施形態の別の態様によれば、スプレッドシートプログラミングのための追加の方法が提供される。本方法は、関数呼び出し及び／又はリモートコールバックを含むスプレッドシート内のセルのセル値に応答して、別のアイテムをスプレッドシートに置換するステップを含む。

本実施形態のさらなる態様によれば、スプレッドシートが提供される。スプレッドシートは、二次元アレイに配置された複数のセルを含む。複数のセルのうちの１つ以上は、スプレッドシート内の別のアイテムを置換するためのセル値を含み、セル値は関数呼び出し及び／又はリモートコールバックを含む。

本実施形態の追加の態様によれば、スプレッドシートが提供される。スプレッドシートは、二次元アレイに配置された複数のセルを含む。複数のセルのうちの１つ以上は、変数の複数の値に対応するデータのための複数の隣接する変数値セルを含む。複数の隣接する変数値セルは、複数の隣接する変数値セルのセル範囲の開始及び終了を示すセル値のペアによってユーザ定義される。複数のセルは、また、変数の複数の値によって定義される変数範囲を含む式に応答して、定義された式を有するセルからデータが流入できるスピルエリアを含む。スピルエリアは、変数の複数の値に対応する複数の式解に自動的にサイズ調整される。

本実施形態のさらに別の態様によれば、動的ウェブサイトのプレゼンテーションのための方法が提供される。本方法は、単一のスプレッドシート文書に応答して動的ウェブサイトのプレゼンテーションを生成するステップを含み、単一のスプレッドシート文書は、データ及びビジネスロジックを含み、動的ウェブサイトのプレゼンテーションのための方法は、単一のスプレッドシート文書のデータ及びビジネスロジックに応答して生成される。

本実施形態のさらに追加の態様によれば、スプレッドシートが提供される。スプレッドシートは、二次元アレイに配置された複数のセルを含む。複数のセルのうちの１つ以上は、非エラー値及び非偽値に評価するように設計されたユーザ指定制約を含む。

本実施形態のさらに別の態様によれば、スプレッドシートプログラミングの方法が提供される。本方法は、非エラー値及び非偽値を評価するように設計された制約を含むように、スプレッドシートの１つ以上のセルをユーザ指定するステップを含む。本方法は、スプレッドシートの１つ以上のセルの少なくとも１つに対してアクションを実行するステップと、制約の少なくとも１つが失敗する原因となったアクションに応答して、アクションを拒否するステップと、制約の少なくとも１つが失敗する原因となったアクションに応答して、スプレッドシートをアクションが実行される前の状態に復元するステップと、を含む。

本実施形態のさらなる態様によれば、スプレッドシートのセルの任意のブロック内の値の検索を加速する方法が提供される。本方法は、空間インデックスを利用するステップと、可能なセル値の全順序を定義するステップと、を含む。

本実施形態の最後の態様によれば、スプレッドシートが提供される。スプレッドシートは、複数の行と複数の列によって定義される二次元アレイに配置された複数のセルを含む。複数の行のそれぞれは、ビグナム（ｂｉｇｎｕｍ）行番号によって識別され、複数の列のそれぞれは、ビグナム列番号によって識別される。各ビグナム行番号及び各ビグナム列番号は、その二進表現において任意の高い有限精度が可能な数を含む。

同様の参照数字が別々の図を通して同一又は機能的に類似の要素を示し、以下の詳細な説明と共に本明細書に組み込まれ、その一部を構成する添付の図は、様々な実施形態を例示し、これらの実施形態に従って様々な原理及び利点を説明するのに役立つ。

本実施形態による例示的なスプレッドシートスピルの図である。 本実施形態によるスプレッドシート振動スピルエリアの図であり、潜在的な振動スピルエリアを示す。 本実施形態によるスプレッドシート振動スピルエリアの図であり、振動スピルエリアの第一の状態を示す。 本実施形態によるスプレッドシート振動スピルエリアの図であり、振動スピルエリアの第二の状態を示す。 本実施形態によるスプレッドシート振動スピルエリアの図であり、振動スピルエリアの安定した最終状態を示す。 本実施形態による置換による再利用ロジックであり、例示的な税計算シートを示す。 本実施形態による置換による再利用ロジックであり、置換可能なセルが定義された図３Ａの例示的な税計算シートを示す。 本実施形態による置換による再利用ロジックであり、図３Ｂの例示的な税計算シートにおける値の置換後の例示的な税計算シートを示す。 本実施形態による単純置換及び入れ子置換のルールを例示するシートであり、図４Ｂ及び図４Ｃの置換の例で使用される第一のシートを示す。 本実施形態による単純置換及び入れ子置換のルールを例示するシートであり、単純置換を示す。 本実施形態による単純置換及び入れ子置換のルールを例示するシートであり、入れ子置換を示す。 本実施形態によるコールバックルールを例示するシートであり、ラベル付きシートを示す。 本実施形態によるコールバックルールを例示するシートであり、図５Ａのシートへのコールバックを示す。 本実施形態によるコールバックルールを例示するシートであり、ラベル付きシートを示す。 図５Ｃのシートへのサンクコールバックを示す。 本実施形態によるスピルバリアのルールの動作を示しスピルバリアが定義されているシートである。 本実施形態によるスピルバリアのルールの動作を示しスピルバリアが追加値を収容するために弾性行のセルを自動的に作成する置換されたシートである。 本実施形態によるラベル位置式の使用を示す。 本実施形態によるスタイル領域のルールの動作を示し、スタイル表である。 本実施形態によるスタイル領域のルールの動作を示し、図８Ａのスタイル表によって定義されたスタイル領域を有するシートである。 本実施形態によるスタイル領域のルールの動作を示し、スプレッドシートの３行／２列部分に対してプログラムされたスタイル領域の表である。 本実施形態による表内表（ＴＷＩＴ）のルールの動作を示し、タイトルセルの下に不快に広いセルを有するシートを示す。 本実施形態による表内表（ＴＷＩＴ）のルールの動作を示し、より良い視覚的外観を提供するために定義されたＴＷＩＴを有する図９Ａのシートのコンテンツを示す。 本実施形態によるディレクトリとしてのクラス（ｃｌａｓｓ）の動作を示し、矩形クラス（ｃｌａｓｓ）の表の作成を示す。 本実施形態によるディレクトリとしてのクラスの動作を示し、矩形の面積の計算を示す。 本実施形態に従って、特定のノードで図１０Ａ及び図１０Ｂによって説明された文書をインポートするスプレッドシートを示す。 本実施形態による動的アンケートウェブサイトを定義するスプレッドシートの図であり、アンケート回答にエントリする前のスプレッドシートを示す。 本実施形態による動的アンケートウェブサイトを定義するスプレッドシートの図であり、１つのアンケート回答にエントリした後のスプレッドシートを示す。 本実施形態によるユーザインターフェース層へのエントリポイントにおける「ｉｎｄｅｘ」マクロの実行後にレンダリングされたスプレッドシートを示し、式「ｊｏｅ＿ｉｄ －│（ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ）：」によって示される矩形領域が空白を含まない場合に、レンダリングされたスプレッドシートを示す。 本実施形態によるユーザインターフェース層へのエントリポイントにおける「ｉｎｄｅｘ」マクロの実行後にレンダリングされたスプレッドシートを示し、式「ｊｏｅ＿ｉｄ －｜（ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ）：」によって示される矩形領域が空白を含む場合に、レンダリングされたスプレッドシートを示す。 購入データを含むスプレッドシートを示し、そのクエリは、本実施形態による空間インデックスの使用によってクエリを高速化することができる。 本実施形態による表内表（ＴＷＩＴ）を有するスプレッドシートを示す。 本実施形態による表内表（ＴＷＩＴ）を有するスプレッドシートを示す。 本実施形態による表内表（ＴＷＩＴ）を有するスプレッドシートを示す。

当業者なら、図中の要素が単純化して、明確化するために図示されており、必ずしも縮尺通りに描かれていないことを理解するであろう。

以下の詳細な説明は、本質的に単なる例示であり、本発明又は本発明の適用及び用途を限定することを意図していない。さらに、本発明に先行する背景技術、又は以下の詳細な説明で提示されるいかなる理論にも拘束されることを意図していない。本実施形態の意図は、ユーザ向けのスプレッドシートベースのプログラミング言語を提示することであり、そのことによって、ユーザが、二次元（２Ｄ）スプレッドシートの制約の中に完全に留まりながら、ロジックブロックを構築、テスト、再利用し、動的ウェブサイトを構築し、大規模な共有スプレッドシートを構築することが可能になる。さらに、その意図は、２Ｄスプレッドシートを今日の汎用プログラミング言語と対等の立場に置くことである。

多くのビジュアル言語が、汎用プログラミングを大衆にもたらすことを追求して発明されたが、画面上で小さな図形をドラッグすることは、表現力が非常に限られており、あまりにも面倒であることが判明してきた。いくつかのビジュアル言語は、信号処理用のＭＡＴＬＡＢ(登録商標) Ｓｉｍｕｌｉｎｋ、及びゲームプレイ要素をスクリプト化するＵｎｒｅａｌゲームエンジンのＢｌｕｅｐｒｉｎｔｓ等、グラフィック表現にうまく対応するニッチな分野で生き残っているが、そのいずれも、汎用のプログラミング環境として実行可能だと考えられていない。

セルの二次元配列を有する２Ｄスプレッドシートの視覚環境に戻って参照すると、今日の従来のスプレッドシートでは、１つのセルに対する式を定義することは、かなり簡単である。セルは、その座標によって、例えば、Ａ１等によって、又はラベルを割り当てることによって、参照することができる。この実施形態によれば、ラベルを割り当てる方法は、専らセルの参照に利用される。

従来のスプレッドシートでは、エリアを埋めることは、基本的に式のコピーとペーストに依存している。行が途中に挿入されたとき、又は式の１つがユーザによって変更されたときに、セルがどのように動作すべきかは、決定が困難である。新しい行３６６５ａは、現在のパターンで自動的に埋められるべきか。同じ式の変更が、そこからペーストされたセルに適用されるべきか？この曖昧さはそれ自体危険であるが、より重要なことは、この曖昧さが、スプレッドシートのロジックを確実に再利用しようとする努力を妨害することである。

現在のスプレッドシートシステムの中には、この問題を軽減するために配列式を有するものがある。しかしながら、ユーザは、式を適用するためにセルの範囲を明示的に指定しなければならず、入力範囲のサイズが変わったときに何が起こるかは、まだ明確ではない。このコピーされたロジックの脆弱性及び他の従来のスプレッドシートの問題を認識して、現在ある従来のスプレッドシートプログラムの欠点を克服するために、本実施形態による複数のスプレッドシートプログラミングルールを定義する。

本実施形態の第一の態様によれば、スプレッドシートにおけるセルの範囲の堅牢で有利な自動充填のために、セルスピルエリアが定義される。図１を参照すると、図解１００は、本実施形態による例示的なスプレッドシート１０５におけるスプレッドシートスピルを示す。ユーザは、サイズを指定することなく、エリア１３０の左上のセル１２０に、単一の式１１０を定義するだけである。ヘッド１２０は、式１１０を必ずしも単一の値に評価するわけではないが、本実施形態によれば、式１１０を値の矩形表に評価することができる。そして、値は、必要に応じて、式を有するセルの右側及び下側のセルにスピルする。スピルエリア内のいずれかのセルが既に設定された値を有するか、又は別のセルからもスピルされる場合、スピル競合が本明細書で論じるように報告される。

式１１０において、＃ｂｉｌｌｉｎｇ＿ｒａｔｅは、ｂｉｌｌｉｎｇ＿ｒａｔｅ：Ｚｂｉｌｌｉｎｇ＿ｒａｔｅの省略形変数であり、ラベルｂｉｌｌｉｎｇ＿ｒａｔｅのセルからラベルＺｂｉｌｌｉｎｇ＿ｒａｔｅのセルまでの隣接する変数値セルの矩形エリアを示すユーザ定義のラベルのペアであり、変数＃ｂｉｌｌｉｎｇ＿ｒａｔｅの複数の値に対応するデータ１００＼＼１５０＼＼６０を含んでいる。同様に、＃ｈｏｕｒｓは、ｈｏｕｒｓからＺｈｏｕｒｓまでの隣接する変数値セルの矩形エリアを示す。例示的なスプレッドシート１０５では、セル１２０の式１１０ ＃ｂｉｌｌｉｎｇ＿ｒａｔｅ＊＃ｈｏｕｒｓは、２つの表、エリア１３２に対する１００＼＼１５０＼＼６０とエリア１３４に対する１０＼＼２＼＼１０を掛け合わせて、３行１列の表１０００＼＼３００＼＼６００を生成する。この表はセル１２０自体に収まらないので、下の２つのセルにスピルし、セル１２０のスピルエリア１３０を生成する。続いて、式１５０において、シート１０５で定義された明示的なラベルＺａｍｏｕｎｔを用いずに、＃ａｍｏｕｎｔは、セル１２０ａｍｏｕｎｔのこのスピルエリア１３０を示し、これは、セルａｍｏｕｎｔそのものも含む。このようにして、セル１４０の式Ｓｕｍ（＃ａｍｏｕｎｔ）１５０全体は、セル１２０ａｍｏｕｎｔのスピルエリア１３０の総和を計算し、１０００＋３００＋６００＝１９００となる。

特に注目すべきは、スピルエリアが振動する問題である。次に図２Ａ、図２Ｂ、図２Ｃ、及び図２Ｄを参照すると、図解２００、２２０、２４０、２６０は、本実施形態に従った問題を例示するスプレッドシートを示している。図解２００において、関数Ｚｅｒｏｓ（ａ，ａ）２０５は、「２」に等しく設定されたセル２１５ａ内のａに応答して、ゼロで満たされたサイズａ×ａの表２１０を生成する。

ユーザが、スプレッドシート２２０のセル２１５ｂに示されるように、値ａを「３」に変更すると、スプレッドシートは次に２つの状態の間で振動することになる。図解２２０（図２Ｂ）に示す状態１であって、左上のセル２２５ａのスピルエリアを３ｘ３に拡大し、セル２１５ｂにスピル競合を報告させ、それによって、セル２２５ａの再評価を保留させた状態と、図解２４０（図２Ｃ）に示す状態２であって、左上のセル２２５ｂがエラー値を有し、したがって、自身を超えるスピルエリアを有さず、セル２１５ｃがスピル競合のない「３」という値を有する状態である。

振動するスピルエリアの問題に対処するために、また本実施形態の一態様によれば、スピルエリアルールは、スピルエリアが非縮小であること、すなわち、スピルエリアを後続のユーザ入力の前にのみ拡大することができると定義される。このスピルエリアルールに従って、左上セルのスピルエリアは、状態２においても３×３のスピルエリア２６５のままに留まり、その結果、図解２６０（図２Ｄ）に示す安定した最終状態となる。

本実施形態によれば、このスピルエリアルールは、有利には、新しいユーザ入力がない場合、常に定常的な最終状態をもたらすことになる。直感的には、互いに競合するスピルエリアのペアの数は、定義された式のペアによって上限が設定される。スピルエリアが縮小できない場合、そのような関係の数は、定常値に収束しなければならない。スピルエリア競合関係が安定すると、セル値は曖昧さなく計算されるか、さもなければ、セル値は依存ループの一部であり、容易に検出されてそのように報告され得る。

従来のスプレッドシートの別の問題は、別のスプレッドシートで定義されたロジックを再利用することが困難なことである。図３Ａを参照すると、図解３００は、個人のための仮想的な税額を計算するように定義されているシート３１０を示す。ロジックが明確に書き出されているにもかかわらず、従来のスプレッドシートは、シート３１０に定義されたロジックを別の個人の税金に適用する適切な方法を提供しない。収入（ｉｎｃｏｍｅ）、子供の数（すなわち、ｎｂ＿ｃｈｉｌｄｒｅｎ）等の入力値が再定義され、したがって、現在計算された値が破壊されるか、又は、コードの複製は、プログラミングで通常強く推奨されないにもかかわらず、ロジックは別のシートに複製され、そこで適所で修正されなければならない。

従来のスプレッドシートにおけるこの欠陥を克服するために、置換ルールが本実施形態によって定義され、置換によるロジックの再利用をサポートする。図３Ｂを参照すると、図解３３０は、置換可能なセル３４２、３４４、３４６、３４８（Ｘで始まるそれらのラベル）が定義されたシート３３５を示している。シート３３５では、セル３４０は、税金を計算するためのロジックである税（Ｔａｘ）の戻り（Ｒｅｔｕｒｎ）値となるように定義することができる。例えば、コードは、ｔａｘ（ｉｎｃｏｍｅ＝１０６０００， ｎｂ＿ｃｈｉｌｄｒｅｎ＝２， ｄｏｎａｔｉｏｎｓ＝１０００＼＼２０００＼＼３０００）と記述することができ、別の仮想の人に対する税金を計算することができる。このコードは、図３Ｃに示すように、少し修正した税（ｔａｘ）の置換シートを表しており、置換シートの＃Ｒｅｔｕｒｎの値を値としている。シート３３５の位置入力は、Ｘ０、Ｘ１のようなラベルが定義されていればサポートされる。

図３Ｃを参照すると、図解３６０は、コードｔａｘ（ｉｎｃｏｍｅ＝１０６０００，ｎｂ＿ｃｈｉｌｄｒｅｎ＝２，ｄｏｎａｔｉｏｎｓ＝１０００＼＼２０００＼＼３０００）で表されるシート３６５を示す。シート３６５は、シート３３５のｔａｘからコピーされ、セルＸｉｎｃｏｍｅ ３７０がコード１０６０００ ３７２に、セルＸｎｂ＿ｃｈｉｌｄｒｅｎ ３７４がコード２ ３７６に、セルＸｄｏｎａｔｉｏｎｓ ３７８がコード１０００＼＼２００００＼＼３０００ ３８０に、それぞれ置換されている。Ｘｄｏｎａｔｉｏｎｓ：ＺＸｄｏｎａｔｉｏｎｓの範囲にある他のセルのコードセットも削除され、すなわち、シート３３５のＺＸｄｏｎａｔｉｏｎｓ＝２００が削除される。ラベルＺＸｄｏｎａｔｉｏｎｓを削除することにより、有利には、コード１０００＼＼２００００＼＼３０００ ３８０で定義されるＸｄｏｎａｔｉｏｎｓの値は、その下のセルにうまくスピルすることができ、一方、＃Ｘｄｏｎａｔｉｏｎｓの意味は、十分に定義されたまま、ユーザの期待に適合する。

位置入力は、Ｘ０、Ｘ１のパターンのラベルを使用してサポートされる。例えば、コードｔａｘ（１０６０００， ２， ｄｏｎａｔｉｏｎｓ＝１０００＼＼２０００）は、コード１０６０００でＸ０、コード２でＸ１を置換し、名前付き入力Ｘｄｏｎａｔｉｏｎｓを前述のように置換することになる。

上記で定義された置換の問題点は、入れ子置換である。図４Ａ及び図４Ｂを参照すると図解４００、４３０は、シート４１０ ａｄｄ、及び４４０ ｓｑｕａｒｅ＿ａｄｄを示す。ｓｑｕａｒｅ＿ａｄｄ（２０）を評価したい場合、曖昧さが生じる。ｓｑｕａｒｅ＿ａｄｄ．Ｘ０に置換する必要があることには曖昧さがなく、これにより、ｓｑｕａｒｅ＿ａｄｄ．Ｒｅｔｕｒｎはａｄｄ（４００）を要求する。さらに、シート４１０のａｄｄでは、Ｘ０に４００を置換すべきであることに曖昧さはないが、ａｄｄ．Ｒｅｔｕｒｎでは、ｓｑｕａｒｅ＿ａｄｄ．Ｘ０が何であるべきかは明確ではない。解釈は２つ考えられる。第一の解釈は，置換ａｄｄ（４００）では、ｓｑｕａｒｅ＿ａｄｄ．Ｘ０は置換されないので、ｓｑｕａｒｅ＿ａｄｄ．Ｘ０は１０であるべきであるというものである。この第一の解釈は単純置換と呼ばれ、置換回数が少ないので、パフォーマンスが高いが、多少驚くかもしれない。第二の解釈は、ａｄｄ（４００）が置換ｓｑｕａｒｅ＿ａｄｄ（２０）の中で入れ子になっており、ｓｑｕａｒｅ＿ａｄｄ．Ｘ０が２０として置換されているので、ｓｑｕａｒｅ＿ａｄｄ．Ｘ０は２０であるべきであるというものである。この第二の解釈は、入れ子置換と呼ばれ、計算コストが高くなる。

両方の解釈にはその用途があるので、第二の解釈は、第一の解釈と異なるように区別して指定するために、二重括弧を使用して表記される。そこで、図４Ｃの図解４６０のシート４７０を参照すると、第二の解釈が望まれる場合、シートｓｑｕａｒｅ＿ａｄｄのＲｅｔｕｒｎセル４７５は二重括弧を使用して書かれる。

上記で定義された置換に関する別の問題は、通常、多くのセルが表で置換されることを意図していないことである。例えば、タックスシートは、置換ｎｂ＿ｃｈｉｌｄｒｅｎ＝１＼＼３を念頭に置いて設計されておらず、好ましくは、エラーを発生させるべきである。したがって、本実施の形態によれば、置換値の形状は元の形状と一致する必要がある。ｘしたがって、本実施の形態によれば、置換値の形状は元の形状と一致する必要がある。すなわち、元のタックスシートの＃Ｘｎｂ＿ｃｈｉｌｄｒｅｎは単一セルであるので、その置換値も単一セルでなければならない。同様に、＃Ｘｄｏｎａｔｉｏｎｓは元々列であるから、その置換も列でなければならない。単一セルは列の特殊なケースと考えられるので、ここでの置換も許容される。４つの形状、すなわち、単一セル、行（単一セルも可）、列（単一セルも可）、及び完全な表（前の３つの形状全てが可）は、区別される。この特徴では、ｔａｘ（ｎｂ＿ｃｈｉｌｄｒｅｎ＝１＼＼３）は、「Ｓｈａｐｅ ｍｉｓｍａｔｃｈ」というエラーが発生する。

本実施形態によるスプレッドシートが、従来のプログラミング言語における関数と類似の働きをすることが示された。同様に、スプレッドシートは、従来の関数のように、パラメータで部分的に拘束されることができる。シート名は、ラベルの値への置換の可能な空のセットと共に、本実施形態に従って、サンク（ｔｈｕｎｋ）と呼ばれる。セルは、その値としてサンクを割り当てることができる。本実施形態のさらなる態様によれば、サンクは、関数の引数として渡すことができ、コールバック及び／又は高次関数を使用することができる。図５Ａ及び図５Ｂを参照すると、図解５００、５２０は、ａｄｄ１という名前のシート５０５、及び本実施形態に従ったコールバックのルールを例示するシート５２５を示す。シート５２５は、コールバックａｄｄ１を、組み込み関数であるマップ（Ｍａｐ）への呼び出しに渡す。

さらに、上記の例に加え、全てのＮについてａｄｄＮを定義しなければならないのは非現実的であることに留意されたい。図５Ｃ及び図５Ｄを参照すると、図解５４０、５６０は、本実施形態による部分的に拘束されたサンクコールバックのためのルールを例示するシート５４５、５６５を示す。シート５４５がａｄｄという名前の場合、式ａｄｄ｛１｝５７０は、シート５４５ａｄｄの部分結合を表し、ａｄｄ１ ５０５と機能的に等価なサンクを生成する。サンクは、さらに置換を取り、さらなるサンクを作ることもできる。一例として、以下：（ａ）ａｄｄ（１，２）、（ｂ）＃ａｄｄ｛１，２｝．Ｒｅｔｕｒｎ、（ｃ）ａｄｄ｛１，２｝（）、（ｄ）ａｄｄ｛１｝（２）、（ｅ）ａｄｄ｛１｝｛２｝（）は全て等価である。

本明細書で論じた単純置換対入れ子置換の区別（）及び（（））と同様に、サンク置換は、それぞれ｛｝及び｛｛｝｝で示されるように、単純か入れ子のいずれかにすることができる。

範囲置換が許可されているので、セルのブロックがどれほど離れて配置されても、全ての考えられるスピル競合を回避することはできない。スプレッドシート３６０（図３Ｃ）を参照すると、誰かが４つを超える寄付（ｄｏｎａｔｉｏｎ）をした場合、Ｒｅｔｕｒｎセルがスピル競合することになる。したがって、本実施形態に従って、スピルバリアのためのルールが定義される。図６Ａ及び図６Ｂを参照すると、図解６００、６５０は、本実施形態によるスピルバリアルールの操作を示す。図解６００は、本実施形態に従って、スピルエリアに対する弾性限界を確立するために定義されたスピルバリア６２０を有するタックスシート６４０を示す。スピルはバリアを越えることができず、代わりに、バリアは、スピル値を含むために、必要に応じて弾性スピルエリアを作成する。弾性スピルエリア内のセルは、ユーザ定義のラベル又は式を有することができない。図解６５０の代替タックスシート６６０において、スピルバリア６２０は、さもなければ、スピル競合を引き起こすであろう追加の寄付値を収容するために、弾性スピルエリア内の行６７０のセルを自動的に作成することを可能にする。

図７を参照すると、図解７００は、スプレッドシート７１０を示す。ユーザが、シートの全てのコンテンツを示す範囲を表現したいと仮定する。Ｘｂｉｌｌｉｎｇ＿ｒａｔｅとＸｈｏｕｒｓはどちらも置換可能であり、それゆえ、任意の高さを有することができることに注目し、ユーザはラベル位置式を使用して、必要なロジックを正確に記述することができる。ラベル位置式とは、ラベルが参照する値ではなく、ラベルの座標を操作する式である。例としては、（ａ） Ｘｂｉｌｌｉｎｇ＿ｒａｔｅ＾＾１は、ラベルＸｂｉｌｌｉｎｇ＿ｒａｔｅの１行上のセルの座標を意味し、（ｂ） Ｚ（Ｘｂｉｌｌｉｎｇ＿ｒａｔｅ）は、セルＸｂｉｌｌｉｎｇ＿ｒａｔｅのスピルエリアの右下隅、すなわち、値６０のセルを意味し、（ｃ） ＢｏｔｔｏｍＲｉｇｈｔ（Ｚ（Ｘｂｉｌｌｉｎｇ＿ｒａｔｅ）， ｌａｓｔ＿ｒｅｍａｒｋ）は、Ｚ（Ｘｂｉｌｌｉｎｇ＿ｒａｔｅ）とｌａｓｔ＿ｒｅｍａｒｋの両方の下、又は右、又は右下にある最も左上のセル、すなわち、ｌａｓｔ＿ｒｅｍａｒｋの下の空のセルを意味する。これらの定義により、ユーザは、Ｘｂｉｌｌｉｎｇ＿ｒａｔｅとＸｈｏｕｒｓをどのような値と置換しても、「シート上の全てのコンテンツ」という概念を、式Ｘｂｉｌｌｉｎｇ＿ｒａｔｅ＾＾１ ： ＢｏｔｔｏｍＲｉｇｈｔ（Ｚ（Ｘｂｉｌｌｉｎｇ＿ｒａｔｅ）， ｌａｓｔ＿ｒｅｍａｒｋ）でエレガントに表現できる。

スプレッドシートにスタイルを設定する通常の方法は、手動でエリアを選択し、次に適用するスタイルを選択することである。これは、スピル及び置換に直面すると破綻する。したがって、本実施形態に従って、ユーザは各シートに対して複数のスタイル領域を定義することができ、優先順位をランク付けできる。スピルエリアとは異なり、スタイル領域は重なり合うことができる。重なり合う領域のセルは、全てのカバー領域からスタイル指定子を蓄積する。指定されたスタイルが競合する場合は、より高い優先順位を有するものが有効になる。各スタイル指定子は、それ自体が２Ｄ表に評価される通常の式であり、領域全体を埋めるためにタイル化される。例えば、図８Ｂのシート８３５に対して、優先度の高いものから低いものへとランク付けされた、以下のスタイル領域を指定する。それは、（ａ） ｂｉｌｌｉｎｇ＿ｒａｔｅ＾＾１からａｍｏｕｎｔ＾＾１まで、スタイル“ｆｏｎｔ－ｗｅｉｇｈｔ”＆“ｂｏｌｄ”、（ｂ） ａｍｏｕｎｔからＺ（ａｍｏｕｎｔ）まで、スタイル“ｆｏｎｔ－ｓｉｚｅ”＆Ｗｈｅｒｅ（＃ａｍｏｕｎｔ＞５００，“ｌａｒｇｅ”，“ｎｏｒｍａｌ”）、及び （ｃ） ｂｉｌｌｉｎｇ＿ｒａｔｅ＾＾１からＺ（ａｍｏｕｎｔ）まで、スタイル “ｂａｃｋｇｒｏｕｎｄ－ｃｏｌｏｒ”＆（“ｌｉｇｈｔｇｒａｙ”＼＼“ｗｈｉｔｅ”）＼＼“ｆｏｎｔ－ｓｉｚｅ”＆“ｓｍａｌｌ”の順である。このスタイル定義は、図８Ａの表８００に評価され、第一の行８０５と第二の行８１０で背景色（ｂａｃｋｇｒｏｕｎｄ－ｃｏｌｏｒ）をライトグレー（ｌｉｇｈｔｇｒａｙ）と白（ｗｈｉｔｅ）との間で交互に定義し、第三の行８１５でフォントサイズを小（ｓｍａｌｌ）と定義している。

図８Ｂを参照すると、図解８３０は、先に定義したスタイル定義（ａ）～（ｃ）を組み込んだシート８３５を描いている。第二のルール（ｂ）のフォントサイズ指定子は、表８００の第三の行８１５のフォント色指定子より優先されることに留意されたい。

あるいは、ユーザは、ｔｏラベルを空のままにして、ｆｒｏｍラベルから始まる３行２列の領域にスタイルを適用するために、スタイルに“ｓｐａｎ”＆３＆２を指定することも可能である。領域のスタイルは、一旦定義されると、プログラムによってアクセス可能である。例えば、Ｓｔｙｌｅ（ａ，ｂ）は、セルａからｂまでの範囲のスタイルを取得する。図８Ｃを参照すると、表８６０は、Ｓｔｙｌｅ（ｈｏｕｒｓ， Ｚ（ａｍｏｕｎｔ））がシート８３５に対してどのように評価されるかを示している。表８６０において、Ｓｔｙｌｅ（）コールは、行８６５“ｓｐａｎ”＆３＆２を自動的に生成することに留意されたい。これにより、Ｓｔｙｌｅ（＃ｓｏｕｒｃｅ）を宛先セルに割り当てることによって、ある領域のスタイルを他の領域に容易にコピーすることができる。

セルが非常に広くなると、その下の意味的に無関係なセルが不快に広くなることを強いられる。図９Ａを参照すると、図解９００は、タイトル（ｔｉｔｌｅ）セルの下に不快に広いセルを有する表９０５を示す。従来のスプレッドシートは、この問題を軽減するために、セルをマージすることを可能にしている。しかしながら、セルのマージは、厳密な２Ｄグリッドに違反し、スピル及びスタイル領域等の他の機能と調和させることが困難である。したがって、表内表（ＴＷＩＴ）のルールは、本実施形態に従って定義され、幅広い行と高い列とを分離する。

ユーザはＴＷＩＴを指定することができ、そこでは領域がより大きな表（通常はシート全体の表）の内部のミニ表としてレンダリングされる。行の数、列の数、及び占有される総面積は保存されるが、個々の行の高さ及び列の幅は、それ以外に、セルのコンテンツに自由に適合させることができる。本実施形態によれば、シート９０５において、タイトルからタイトルまでのＴＷＩＴ＞＞２を定義することができる。図９Ｂの図解９１０は、上記定義されたＴＷＩＴを組み込んだシート９１５を示し、これによって、有利には、より良い視覚的外観が提供される。

ＴＷＩＴは入れ子にすることはできるが、交差することはできない。すなわち、２つのＴＷＩＴは、完全に不連続であるか、一方が他方に完全に含まれているが、２つのＴＷＩＴの境界は交差することができない。交差ＴＷＩＴは、交差する境界を有するＴＷＩＴとして定義され、無視される。

シートの列は、整理しにくい。その理由は、従来のスプレッドシートは、全てのシートが一列に並んでいるため、階層がないからである。従来のスプレッドシートプログラムのこの欠陥を克服するために、本実施形態の別の態様に従って、スプレッドシートは階層化される。各シートは、シートがフォルダとファイルの両方として機能することを除いて、フォルダがファイルを含み、またさらにフォルダを含むことができるのと同様に、子シートを有することができる。本実施形態に従ってシートを階層化することには、階層がより論理的である以外に、いくつかの利点がある。例えば、スプレッドシート文書をウェブサイトとしてエクスポートする際に、階層をＵＲＬと容易にマッピングできる。さらに、シートに１つずつメタデータを割り当てるよりも、シートのグループにリード／ライトの許可等のメタデータを割り当てる方が容易である。また、階層は、本明細書で後述するように、クラスを定義するための基礎を形成する。

従来の主流のプログラミング言語のほとんどは、何らかの形でクラスをサポートしている。これは、第一近似では、データと関連する関数の束である。例えば、コールａ．ａｒｅａ（）は、値ａがどのクラスに属するかに応じて、異なるコードを実行する。本実施形態のさらなる態様によれば、スプレッドシート内のセルの値に応答して、動的に指定されたスプレッドシート参照をスプレッドシートに置換することができ、動的に指定されたスプレッドシート参照は、動的に指定されたディレクトリ参照と別のスプレッドシートのスプレッドシート名とが含まれる。したがって、クラスの挙動は、スプレッドシートのコンテキストで理解可能な動的ディレクトリ参照によってエミュレートされる。

表の第一の行が「Ｃｌａｓｓｓ」＆「ｒｅｆｅｒｅｎｃｅ－ｔｏ－ｄｉｒｅｃｔｏｒｙ」であれば、その表は、前記ディレクトリのクラス（ｃｌａｓｓ）であると見なされる。キーワードクラスス（Ｃｌａｓｓｓ）は、ランダムな表が正しいキーワードを持つ可能性を最小限にするために、意図的にスペルミスされているが、実際のキーワードの選択はこの発明の文脈では本質的でない。特殊な構文ａ－＞ａｒｅａ（）は、次に、コールｄｉｒｅｃｔｏｒｙ．ａｒｅａ（ａ）に変換される。式ｄｉｒｅｃｔｏｒｙ．ａｒｅａは、動的ディレクトリ参照とシート名を含む動的シート参照である。一例として、図１０Ａ及び図１０Ｂは、ｒｅｃｔａｎｇｌｅ（矩形）クラスがどのように機能するかの図解１０００，１０５０を示す。図解１０００のｃｒｅａｔｅ（作成）シート１０１０は、幅と高さを与えられたｒｅｃｔａｎｇｌｅクラスの新しい表を作成する関数として機能し、図解１０５０の面積シート１０６０は、矩形の面積を計算する。これらの定義により、以下のようなコード：ｒｅｃｔａｎｇｌｅ．ｃｒｅａｔｅ（ｗｉｄｔｈ＝３， ｈｅｉｇｈｔ＝３）－＞ａｒｅａ（）を適切に定義することができる。代わりに、ｃｉｒｃｌｅ．ｃｒｅａｔｅ（ｒａｄｉｕｓ＝３）－＞ａｒｅａ（）が代わりにｃｉｒｃｌｅ．ａｒｅａというシートを呼び出す方法に留意されたい。構文＃Ｘ０［“ｗｉｄｔｈ”］は、与えられた表＃Ｘ０の第一の列で文字列“ｗｉｄｔｈ”を検索し、その右側の値を式の値として取ることを意味する。

第三者スプレッドシートをインポートすれば、他のユーザと関数及びクラスを共有することが可能になる。したがって、本発明によって、スプレッドシート文書をシートツリーのノードとしてインポートすることが可能になる。図１１を参照すると、図解１１００は、あるノードでシート１０１０，１０６０によって記述された文書をインポートするスプレッドシートを示す。インポートされた文書のディレクトリ構造は保持される。

上述したように、第三者スプレッドシート文書の完全なソースコードがインポートされ、その後、文書の残りの部分と同じコンピュータで実行される。その代わりに、ときどき、インポートされたスプレッドシートが第三者のコンピュータ上に残り、そのコンピュータ上で実行され、ユーザにはその結果のみが通知されることが望まれる場合がある。これには、いくつかの理由が考えられる。例えば、第三者のシートは所有権があり、その作者はソースコードを配布したくない。あるいは、実行がリソース集約的であるか、特殊なハードウェアを必要とし、第三者によって実行されるのが最善である。

本実施形態によれば、異なるコンピュータに存在する複数のシートが１つの論理的な分散文書を形成することを可能にする。この種のシステムにおける主要な課題は、サイクル検出であり、そこでは、コンピュータＡに存在するあるセルａがコンピュータＢに存在するあるセルｂに依存し、そのセルｂがコンピュータＣに存在するあるセルｃに依存し、さらにそのセルｃがセルａに依存している。本例のように任意のセルが任意の可能な遠隔セルを参照できる完全一般システムにおいて、依存性検出は困難な問題である。そこで、本発明は、有用性を保ちつつ作業しやすい限定的な星型形態を提案する。

１つのコンピュータのみが文書のハブとみなされ、任意のリモートシートを好きなように参照することができる。ライブラリと呼ばれる他のコンピュータは、ハブからパラメータとして渡されたリモートサンクを経由する以外、ハブ又は任意の他のコンピュータを参照し返すことはできない。例えば、ある人がチケット管理システムをシートの集合体として開発したが、そのシートはソースコードを公開したくないので、チケット管理システムは開発者のコンピュータでライブラリとして動作する。そして、ユーザはこのライブラリをリモートシートとして取り込むことができる。しかしながら、どのユーザがログインできるのか、どのチケットにアクセスできるのか、ライブラリはそれ自体では分からないので、これは、本来、ユーザが設定すべきポリシーである。そこで、設定として、ユーザは、ａｕｔｈｅｎｔｉｃａｔｅｄサンクとａｕｔｈｏｒｉｚｅｄサンクを渡し、それぞれパスワード認証とアクセス制御のルールを定義する。これらのサンクはユーザのコンピュータに残り、サンクＩＤのみがライブラリを実行しているコンピュータに渡される。ライブラリがサンクを実行する必要があり、サンクＩＤがローカルで利用できないことが分かると、第三者システムは、ユーザのコンピュータ（通称ハブ）にサブスクライブ要求を送り返すことになる。

本実施形態による依存関係ループ検出は、星形の依存関係が維持されることによって、より単純化される。ハブによって参照される２つのライブラリは、互いに直接話すことができず、文書のハブとだけ話すことができる。ライブラリがセル値の更新をハブに公開すると、この値を計算するために使用されたハブ上の全ての値もリストアップされる。このようにして、依存ループがあるときはいつでも、ハブはそれを簡単に検出し、関連するセルに依存ループエラーを設定することができる。ライブラリは、更なるライブラリがハブから見えない限り、更なるライブラリのハブとして自由に動作することもできることに留意されたい。つまり、チケット管理ライブラリは、それ自身が他のライブラリをインポートすることができるが、ユーザにはまだ単一のモノリスとして表示される本実施形態に従うループ検出アルゴリズムは、チケット管理ライブラリの内部実装に依存しない。

本実施形態に従って、コラボレーティブシートが提供される。最も単純な場合、コラボレーティブシートは、同じバックエンドに接続された複数のＵＩに過ぎず、そのそれぞれがセルのコードの設定及び水平バリアの設定といったコマンドを送信し、バックエンドからセルの更新を受信する。

アクセス制御が可能になると、事態はさらに興味深いものになる。従来のコラボレティブスプレッドシートシステムは、アクセス制御が非常に粗い。例えば、Ｇｏｏｇｌ（登録商標） シートは、ユーザが文書を編集できるかどうか、ユーザが文書を読めるかどうか、ユーザが文書にコメントできるかどうか等、文書全体に対して、ユーザごとにいくつかの許可ビットを有する。しかしながら、このような単純化されたモデルは、しばしば適切ではない。

例えば、企業は、全ての管理及び運用データを１つの巨大な文書に収めたいと考えることがある。人事データは１つのサブツリーに格納され、人事部員だけが見ることのできる全員の給与等の機密情報も含まれている。顧客サポートのデータは、別のサブツリーに格納されている。このサブツリーでは、顧客サポートチームがチケット管理システムの構築を計画している。同チームは、チケット管理システムで役割を割り当てるために、機密情報ではない、誰がどの部署にいるかという人事部の記録を使いたいと考えている。同チームは人事データに直接アクセスすることはできないので、人事部の誰かが部門情報を抽出し、顧客サポートチームがそのデータを読むことができるように特別な許可を与える必要がある。

明らかに、このようなシナリオでは、従来のシステムの粗いアクセス制御では不十分である。しかしながら、各シートに対して誰が読み取りと書き込みができるかを単純に定義する素朴なアプローチは、簡単に回避できる。例えば、シートｓｅｃｒｅｔが人事部にのみアクセス可能であり、シートｐｕｂｌｉｃが誰でも読み書き可能であるとする。どのユーザも、シートｐｕｂｌｉｃのセルＸにコードｓｅｃｒｅｔ．ｅｖｅｒｙｏｎｅｓ＿ｓａｌａｒｙを設定し、シートｐｕｂｌｉｃのセルＸを読み取ることが容易にできる。

本実施の形態による操作は、シートごとの所有者と読者を定義する。シート単位の所有者と読者は、実際のユーザである具体的なユーザと、あるユーザ集合の共通項である抽象的なユーザを含む。具体的なユーザと抽象的なユーザを合わせて、ユーザとする。各ユーザは、他のユーザの集合体として行動することができる。例えば、ある仮想的な企業には、次のようなユーザがいる：（ａ）全人員：システム内のあらゆるユーザ（これは常に存在し、誰もが人員として行動（ａｃｔ－ａｓ）できる）、（ｂ）人事部人員（例えば、人事に従事する人で人員として行動できる）、（ｃ）顧客サポート人員（例えば、顧客サポートに従事する人）、（ｄ）マネージャー（例えば、あらゆるマネージャー）、（ｅ）人事部マネージャー（例えば、人事部でマネージャーとして行動できる）、（ｆ）チェスクラブ人員、（ｇ）Ｔｙｒｉｏｎ（例えば、人事部マネージャーとチェスクラブ人員として行動できる）、（ｈ）Ｓａｍｗｅｌｌ（顧客サポート担当者とチェスクラブ人員として行動できる）がいる。

としての行動（ａｃｔ－ａｓ）関係は推移的であるので、例えば、Ｔｙｒｉｏｎは、人事部人員として行動（ａｃｔ－ａｓ）することも可能である。

本実施形態によれば、全てのシートはその所有者として１人のユーザがあり、これは静的に割り当てられなければならない、すなわち、計算されない。シート内の全ての式は、誰がシートを見ているかに関係なく、常に所有者の許可を得て実行される。このようにして、許可拒否エラーも含めて、誰もが同じ値を得ることができる。

本実施形態によれば、全てのシートは、その読者としてゼロ又はそれ以上のユーザを有することができる。このリストは、計算されることができ、例えば、個人情報を示すシートが、誰の情報が示されているかに依存する読者リストを有するように、置換可能なセル値に依存することができる。これは、自分の情報は読ませるが、他の人の情報は読ませないという場合に有効である。ユーザは、自分が所有者、又は読者の少なくとも１人として行動できる場合、シートを読むことができる。

本実施の形態によれば、ユーザは、（自分が）所有者として行動できる場合、読者のリストを含むシートを編集することができる。シートの所有者を変更するためには、ログインしたユーザは、古い所有者と新しい所有者の両方をして行動できなければならない。ある人がシートを編集できるのは、その人が所有者として行動できる場合のみであり、シートは所有者の許可を得て評価されるので、セルに式を書いても権限昇格はできない。

きめ細かな許可が必要でない場合は、全てのシートの所有者は人員に設定される。これもデフォルトである。

本実施の形態によれば、各シートに対して複数の所有者を許容することができる。次いで、シート内のコンテンツは、全ての所有者の共通項で実行される。すなわち、他のシートからセルを読み取ることができるためには、全ての所有者ができる必要がある。その後、ユーザは、いずれかの所有者として行動できれば、新しい所有者を追加することを含め、シートを編集することができる。本質的に、全ての所有者の共通項である無名の単一所有者が存在する。

スプレッドシートの概念は、平均的なコンピュータユーザがアクセスできる唯一のプログラミング環境であることが長い間証明されているが、スプレッドシートの概念を中心とした単純な動的ウェブサイトでさえ、複数層を構築することは、実現されていない。本実施形態によれば、単一の首尾一貫したスプレッドシート文書が、ＣＲＵＤウェブサイト全体を提供することができる。単純なＣＲＵＤ（作成／読出／更新／削除）ウェブアプリケーションにおいてさえ、開発者は、いくつかの層で異なる技術を必要とする。例えば、ＨＴＭＬ、Ｊａｖａｓｃｒｉｐｔ（登録商標）、又はＣａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ（ＣＳＳ）のようなフロントエンド技術は、エンドユーザにユーザインターフェースを提示するために用いられ、ＰＨＰ（オープンソース汎用スクリプト言語であるＨｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ）、Ｊａｖａ（登録商標）又は他の多くの選択肢のいずれかのようなビジネス論理層プログラミング言語は、エンドユーザのクエリ及びアクションをデータベースのクエリ及びアクション（典型的には構造化クエリ言語（ＳＱＬ）に翻訳）に変換するために用いられ、データベースクエリ言語（典型的には同じくＳＱＬで）は、実際にデータをホストするデータベースを制御するために使用されている。

各層で利用可能なプログラミング言語、フレームワーク、パラダイム、及び製品の多くの選択肢を考えると、実務家は、しばしば、機能する製品を構築するために選択された技術を「技術スタック」と呼ぶことがある。例えば、ＭＥＡＮ技術スタックは、データベース層でＭｏｎｇｏＤＢを使用し、ビジネスロジック層でＥｘｐｒｅｓｓ．ｊｓ（Ｊａｖａｓｃｒｉｐｔ（登録商標）のＮｏｄｅ．ｊｓの上に構築）を使用し、ユーザインターフェース層でＡｎｇｕｌａｒＪＳ ｊａｖａｓｃｒｉｐｔ（登録商標）フレームワークを使用し、それゆえ、頭文字でＭＥＡＮと呼ばれる。

技術スタックには、高い参入バリア（すなわち、急な学習曲線）がある。その理由は、単純な技術スタックの基本を学ぶことさえ、プログラミング経験のない人にとって、あるいは関連技術に精通していないプログラマにとっても、数ヶ月の激しい努力を必要し得るからである。プロのウェブ開発者にとって、異なる技術スタックに切り替えることは、依然として困難な作業である。

この基本的な構造とそれに伴う参入バリアは、次のフェイスブックを作るか、単純なウェブアンケートを作るかに関係なく存在する。前者の場合は複雑さが正当化されるのに対し、後者の場合は過度に複雑になり、一見単純に見えることが、専門家以外には完全に不可能になってしまうのである。

現在、静的なウェブサイトとして表示するために、スプレッドシートをＨＴＭＬページとして保存することはできる。しかし、ロジックとレイアウトがスプレッドシートで定義されているにもかかわらず、データソースをクエリし、計算を行うことによって、コンテンツがその場で生成される動的ウェブサイトについては、同じことを言うことはできない。現状では、このようなウェブサイトは、スプレッドシートを参照しながら、再びゼロから実装し直さなければならないが、実際のコードの再利用は不可能である。

図１２Ａを参照すると、ダイアグラム１２００は、動的ウェブサイトを定義するのに役立つ文書アンケートのシート１２０５を示しており、本実施形態に従って、文書は、全てのデータ、ビジネスロジック、及びプレゼンテーションコーディングを含んでいる。ダイアグラム１２００によって表される例は、アンケートウェブサイトを示し、そこでは、教師が、クラスの４人の生徒から３つのフィードバックの質問に対する答えを収集することを望んでいる。データベースを作成して管理する代わりに、教師は、関連するデータを保持するために、スプレッドシート文書アンケートでシートデータ１２０５を作成する。これは、先に説明したデータベース層と類似している。角括弧内のテキストは、セルに割り当てられたラベルを示す。

次に、教師は、提出があった場合に、アンケート結果を記録するビジネスロジックを構築する。具体的には、教師は、以下のコンテンツからなるｏｎ＿ｓｔｕｄｅｎｔ＿ｓｕｂｍｉｔというマクロを作成する。
ＰａｓｔｅＣｅｌｌ！（Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ）－｜ａｎｓｗｅｒ） ＞＞
Ｘｑｉｄ，Ｘａｎｓｗｅｒ；ｉｎｄｅｘ！； （１）

マクロは、従来のスプレッドシートのように、ユーザのアクションをシミュレートする。提出物が以下であると仮定する。
ｓｔｕｄｅｎｔ ＝ ｊｏｅ＠ｓｃｈ．ｅｄｕ
ｑｉｄ＝１
ａｎｓｗｅｒ＝９ （２）
ここで、Ｘｓｔｕｄｅｎｔは、提出時の学生（ｓｔｕｄｅｎｔ）フィールド、すなわち、領域１２１０で検索されるｊｏｅ＠ｓｃｈ．ｅｄｕを指す。

マクロ（２）において、「Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ）」は、コンテンツｊｏｅ＠ｓｃｈ．ｅｄｕ、領域１２１０内のｓｔｕｄｅｎｔ＿ｉｄからｌａｓｔ＿ｓｔｕｄｅｎｔまでのセル範囲内で、セル１２１５の位置を特定する。この例では、それは、ｊｏｅ＿ｉｄというラベルを有するセル１２１５である。

マクロ（２）において、「Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ） －｜ ａｎｓｗｅｒｓ」は、行「Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ）」（すなわち、セル１２１５を含む行１２２５）と列「ａｎｓｗｅｒ」（すなわち、列１２３０）の交点におけるセル１２２０であって、ダイアグラム１２００におけるラベル［ａ］を含むセル１２２０となるであろうことを意味している。

マクロ（２）において、「＞＞ Ｘｑｉｄ」は、Ｘｑｉｄセルだけ右へ移動することを意味する。なお、質問ＩＤは０ベースで、質問ＩＤ０は「どの程度赤ん坊サメを気に入りましたか」という質問１２４０を指し、質問ＩＤ１は「どの程度お母さんサメを気に入りましたか」という質問１２４５を指している。「（Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ） －｜ ａｎｓｗｅｒ） ＞＞ Ｘｑｉｄ」という式全体は、ラベル［ｂ］を含むセル１２５０を参照する。

「ＰａｓｔｅＣｅｌｌ！ｂ，Ｘａｎｓｗｅｒ；」は、あたかもユーザがセル１２５０に当該コンテンツを貼り付けたように、ラベル［ｂ］を含むセル１２５０に提出物の回答フィールドのコンテンツを貼り付ける。そして、「ｉｎｄｅｘ！；」は、以下に説明するように、「ｉｎｄｅｘ」という名前のマクロを呼び出す。

このように、図１２Ｂを参照すると、マクロ実行後、ダイアグラム１２００からのシートデータ１２０５は、ダイアグラム１２６０のシートデータ１２６５のように見え、セル１２５０に新しい答え「９」が記録されている。次いで、マクロ「ｉｎｄｅｘ」が呼び出される。

ユーザインターフェース層のエントリポイントは、「ｉｎｄｅｘ」という名前のマクロ（４）であり、これがデフォルトハンドラとなるように名付けらている。
ｉｆ （ＮｏＢｌａｎｋ（Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ） －｜ （ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ））） ｛
Ｒｅｎｄｅｒ！ ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ＿ａｎｓｗｅｒｓ；
｝
ｅｌｓｅ ｛
Ｒｅｎｄｅｒ！ ｓｈｏｗ＿ａｎｓｗｅｒ＿ｆｏｒｍ；
｝ （３）

前と同様に、式「Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ）：」は、関連するｓｔｕｄｅｎｔ＿ｉｄを含むセル、この場合はセルｊｏｅ＿ｉｄを特定する。式「ｊｏｅ＿ｉｄ －｜ （ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ）：」は、ｊｏｅ＿ｉｄと同じ行、及び領域「ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ」と同じ列をカバーする矩形領域を示す。本実施例では、この式は、Ｊｏｅの回答を含むセルに対して評価される。

図１３Ａ及び図１３Ｂを参照すると、ダイアグラム１３００及び１３５０は、「ｉｎｄｅｘ」マクロの実行後に、レンダリングされたスプレッドシートの２つのオプションを示す。式「ｊｏｅ＿ｉｄ －｜ （ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ）：」で示される矩形領域が空白を含まない場合、スプレッドシート「ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ＿ａｎｓｗｅｒｓ」がレンダリングされる。スプレッドシート「ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ＿ａｎｓｗｅｒｓ」は、ダイアグラム１３００に示されており、等幅テキストは、セルに入力された数式である。数式がセルの領域に対して評価される場合、本明細書で説明したように、その結果は、右側と下側の隣接するセルにスピルすることに留意されたい。

そうではなく、式「ｊｏｅ＿ｉｄ －｜ （ａｎｓｗｅｒ：ｌａｓｔ＿ａｎｓｗｅｒ）：」で示される矩形領域が空白を含む場合、スプレッドシート「ｓｈｏｗ＿ａｎｓｗｅｒ＿ｆｏｒｍ」がレンダリングされる。スプレッドシート「ｓｈｏｗ＿ａｎｓｗｅｒ＿ｆｏｒｍ」は、ダイアグラム１３５０に示されている。スプレッドシート「ｓｈｏｗ＿ａｎｓｗｅｒ＿ｆｏｒｍ」のコンテンツは、学生に「次の質問に答えてください」と提示することにより、学生に与えられた最初の未回答の質問に対する答えをお願いする。

選択肢のスタイルは、“ｉｎｐｕｔ”＆“ｓｅｌｅｃｔ”＼＼“ｏｐｔｉｏｎｓ”＆Ｔ（Ｒａｎｇｅ（１，１０））として定義され、以下の表１に示すように評価される。

これは、ＨＴＭＬレンダラーにセルをＨＴＭＬ選択ボックスとして、所与の選択肢でレンダリングするように指示する。提出（ｓｕｂｍｉｔ）のスタイルは、以下のように定義される。
“ｉｎｐｕｔ”＆“ｓｕｂｍｉｔ”＼＼“ｔａｒｇｅｔ”＆ｏｎ＿ｓｔｕｄｅｎｔ＿ｓｕｂｍｔ”＼＼“ｄａｔａ”＆
（“ｑｉｄ”＆ｑｉｄ＼＼“ａｎｓｗｅｒ”＆ｃｈｏｉｃｅ） （４）
ユーザが８を選択したとすると、スタイルは、表２に示すように評価される。

したがって、提出ボタンがクリックされると、「ｏｎ＿ｓｔｕｄｅｎｔ＿ｓｕｂｍｉｔ」マクロは、上記に示す提出（５）に従って、提出された値で埋められたフィールドＸｑｉｄ及びＸａｎｓｗｅｒを用いて、スプレッドシートエンジンによって実行される。

本実施形態によるスプレッドシートによってレンダリングされるアンケートウェブサイトの存続期間は、以下のようになる。まず、生徒が未回答の質問を有するとき、「ｓｈｏｗ＿ａｎｓｗｅｒ＿ｆｏｒｍ」シートをレンダリングして、回答を募る。次に、回答が提出されると、「ｏｎ＿ｓｔｕｄｅｎｔ＿ｓｕｂｍｉｔ」マクロが呼び出されて、データシートが更新される。そして、生徒が全ての質問に回答すると、「ｓｈｏｗ＿ｃｏｍｐｌｅｔｅｄ＿ａｎｓｗｅｒｓ」スプレッドシートがレンダリングされ、全ての生徒の回答が表示される。その後、教師は、データシートに収集されたデータに対して、通常のスプレッドシートの書式を使用して、提出された回答に対して任意の分析を実行することができる。

［一般に、動的なウェブページは、ユーザが送信したクエリパラメータによって指定された置換後に、スプレッドシートからレンダリングできる。ＵＲＬが要求されると、サーバは、要求ＵＲＬに続くスプレッドシート文書内のルーツ（Ｒｏｏｔ）シートからのパスを、進むことができる。例えば、リクエスト：
ｈｔｔｐ：／／ｄｏｃ．ａｂｃ．ｃｏｍ／ｄｅｍｏ／ｔｉｃｋｅｔ＿ｍａｎａｇｅｒ／ｔｉｃｋｅｔ？ｉｄ＝１２３ （５）
に応答して、サーバは、文書ルートを探し、スプレッドシートファイルｄｅｍｏ／ｔｉｃｋｅｔ＿ｍａｎａｇｅｒを見つけることがある。そのファイルを開き、本実施形態によるＲｏｏｔ．ｔｉｃｋｅｔにあるシートを見つける。Ｘｉｄを１２３に置換し、シートＲｏｏｔ．ｔｉｃｋｅｔをＨＴＭＬにレンダリングする。置換プロセスは、置換されたシート全体が結果としてレンダリングされることを除いて、Ｘプレフィックスを含む関数呼び出しにおけるシート置換と基本的に同じである。

制約は、ＳＱＬデータベースにおける中心的な概念である。これは、データの一貫性を強制するための鍵である。経験豊富なデータベース管理者は、制約がなければ、最終的に悪いデータが忍び込むことを知っている。本実施形態に従って、ユーザは、特定のセル及び／又は数式を「制約」として指定することができ、スプレッドシートに制約をもたらすことができる。そのようなセル及び書式は、常にエラーでも、偽値でもないように評価されなければならない。アクション（一部のセルのコンテンツの変更等）によって１つ以上の制約が失敗すると、アクションは拒否され、スプレッドシート文書は、アクションが試みられる前の状態に復元される。特に、セル又は書式を制約として指定するアクションは、それ自体がこのアクションチェックの対象となることに留意されたい。したがって、セルが現在エラー状態である場合、それを制約として指定することは失敗する。

制約が定義されると、データ所有者は、これらの重要な不変量が支持されるという保証を得る。一例は、制約「ＡｌｌＵｎｉｑｕｅ（＃ｉｄ）」のように、ＩＤ列が一意な値を保持していることをチェックすることがでる。ここで、「＃ｉｄ」はｉｄ列を指し、「ＡｌｌＵｎｉｑｕｅ（）」はそのパラメータ（例えばｉｄ列）が重複を含まない場合にのみ、真と評価される。

他の例は、ｓｋｕセルが実際に存在するＳＫＵ（Ｓｔｏｃｋ Ｋｅｅｐｉｎｇ Ｕｎｉｔ）製品コードを参照しており、以下の式（６）のような「不明」でないことをチェックすることである。
Ｌｏｃａｔｅ（ｓｋｕ， ＃ａｌｌ＿ｓｋｕｓ）） ＆＆ ｓｋｕ ！＝“ｕｎｋｎｏｗｎ” （６）
ここで、「＃ａｌｌ＿ｓｋｕｓ」は、全てのＳＫＵ製品コードを保持する領域を指し、「Ｌｏｃａｔｅ（）」は、その第二のパラメータで指定された領域内の第一のパラメータの位置を検索する。ルックアップに失敗した場合は、エラーが返される。

式（６）のような不変量に違反すると、ビジネスデータが使用不能になることがある。制約の定義によって提供される保証は、スプレッドシートユーザの主な使用例であるビジネスアプリケーションにとって特に重要である。

状況によっては、まず制約を一時的に解除し、複数のユーザアクションの後にのみ復元する必要がある。例えば、前の例でｓｋｕセルのスペルを修正するために、「＃ａｌｌ＿ｓｋｕｓ」と「ｓｋｕ」の関連スペルを両方修正しなければならず、制約に違反するのは、一方だけが修正されたときである。したがって、ユーザは、一時的に制約を無効にすることができる。無効にされた制約は、単に非制約であり、ある時点で復活させるべきであるという視覚的なリマインダがある。

ある列のＩＤをルックアップするための一般的な式を考える。本明細書で上述した図１２Ａ及び図１２Ｂの例で言えば、一般的な式は、以下の式（７）である。
Ｌｏｃａｔｅ（Ｘｓｔｕｄｅｎｔ， ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ） （７）
素朴な実装では、表「ｓｔｕｄｅｎｔ＿ｉｄ：ｌａｓｔ＿ｓｔｕｄｅｎｔ」を順次スキャンして、「Ｘｓｔｕｄｅｎｔ」の値を探す。これは、データベースの文献では一般的に線形スキャンと呼ばれ、リソースを大量に消費する操作となる。このリソースを大量消費する操作を避けるために、データベースはインデックスを構築し、高速なルックアップを可能にする。しかし、データベースのインデックスは、ユーザが定義済みのデータスキーマを提供し、そのスキーマの上にどのようなインデックスを構築するかを提供することに依存している。これは、明らかにスプレッドシートでは実現不可能なことである。例えば、ユーザは、効率的に任意の領域の任意の値を「Ｌｏｃａｔｅ（）」することができるはずである。したがって、本実施形態に従って、スプレッドシート内のセルの任意のブロックにおける値の検索を加速するために、空間インデックスを使用してスプレッドシート内のセル値にインデックスを付ける新規な方法を提案する。

あるまず、可能なセル値の総順序を定義する。例えば、整数は浮動小数点より小さく、浮動小数点は順に文字列より小さく、文字列は順に空白値より小さくなることを任意に定義する。それぞれのデータタイプ内では、通常の順序が適用される。その後、スプレッドシートの状態は、セル行ｙ列ｘにおけるｚの値が（ｘ，ｙ，ｚ）の点によって表される三次元点群として符号化することができる。

あるしたがって、クエリ「Ｌｏｃａｔｅ（ｖａｌｕｅ， ｓｔａｒｔ：ｅｎｄ）」は、スプレッドシートの点群と、以下の式に囲まれた立方体の交点を見つけるための三次元空間の検索である。
Ｃｏｌｕｍｎ（ｓｔａｒｔ） ＜＝ ｘ ＜＝ Ｃｏｌｕｍｎ（ｅｎｄ）， Ｒｏｗ（ｓｔａｒｔ） ＜＝ ｙ ＜＝ Ｒｏｗ（ｅｎｄ）、及び
ｖａｌｕｅ ＜＝ ｚ ＜＝ ｖａｌｕｅ （８）
このような検索は、空間インデックスによって高速化することができ、その中で最もよく知られているのは、Ｒ－ｔｒｅｅインデックスである。以下の議論では、Ｒ－ｔｒｅｅインデックスを使用するが、他のほとんどの空間インデックスも少しの修正で本実施形態に従って使用できることが理解される。

Ｒ－ｔｒｅｅは、点群Ｃを２つの集合（Ｃ１及びＣ２）に再帰的に分割し、各集合のバウンディングボックスを記録する。集合は、可能な限り、バランスよく、コンパクトで、かつ、不連続であるように選択される。Ｒ－ｔｒｅｅの検索は自明な再帰関数であり、Ｒ－ｔｒｅｅ内の点の追加、削除、移動は当業者にはよく知られていることである。

空間インデックスによって高速化できる他のいくつかの表現は、以下の通りである。
ＭｉｎＳｔｒｉｎｇ（ｓｔａｒｔ：ｅｎｄ） ａｎｄ ｆｒｉｅｎｄｓ （９）
ＡｌｌＳａｍｅ（ｓｔａｒｔ：ｅｎｄ）は、単に
Ｍｉｎ（ｓｔａｒｔ：ｅｎｄ）＝＝Ｍａｘ（ｓｔａｒｔ：ｅｎｄ） （１０）
として、加速できる。
ｓｔａｒｔ：ｅｎｄ ＜ ５ （１１）

特別な考慮事項は、＆＆クエリに適用可能である。図１４を参照すると、スプレッドシート１４００は、子供１４２０が購入したスナック１４１０と、購入した日１４３０との長い記録シナリオを示している。スプレッドシート上のクエリは、本明細書で上述したように、本実施形態に従った空間インデックスによって加速することができる。以下のクエリ（１２）は、１人の子供による短い範囲内の日付を有する記録のインデックスを返す。
Ｂｅｔｗｅｅｎ（ｄａｔｅ：Ｚｄａｔｅ， ‘２０２０－０１－２０’，‘２０２０－０１－２１’） ＆＆ ｐｅｒｓｏｎ：Ｚｐｅｒｓｏｎ＝＝“ｌｕｋｅ” （１２）

第一の部分式は、疎で、数少ない記録にしかマッチしない。しかしながら、第二の部分式は、密である。両方の部分式を評価し、その和を見つけるという素朴な戦略では、ブール型ベクトル「ｐｅｒｓｏｎ：Ｚｐｅｒｓｏｎ＝＝“ｌｕｋｅ”」を評価するのに多くの時間が費やされ、そのほとんどが無駄になる。

これを改善するために、クエリが分割・征服されるときに、両方の制約が同時に考慮される。各ステップで、残りの検索エリアは、第一の部分式又は第二の部分式のいずれかに従って分割され、より高い情報量を有する部分式が選択される。日付の方がより識別力が高いので、日付に従って探索エリアを分割することが選択されやすく、その結果、シートの点群を迅速にプルーニングすることができる。

汎用Ｒ－ｔｒｅｅインデックスのような空間インデックスは、多くのタイプのクエリを高速化するために使用することができるが、他のものも依然として特殊なデータ構造から利益を得ることができる。一般的に制約として使用されるセル「ＣｏｌＳｏｒｔｅｄ（ａ：ｂ）」を考えてみよう。この制約は、指定された範囲の全ての列がソートされている場合、つまり、各セルが下のセルより大きくない場合にのみ、真と評価される。

ときどき、スプレッドシートで階層的な領域を定義したいことがある。その例として、ＴＷＩＴ（ｔａｂｌｅ－ｗｉｔｈｉｎ－ｔａｂｌｅ）があり、スプレッドシート内の領域で、その行の高さと列の幅は、本明細書で上述したように、より大きなスプレッドシートの行の高さと列の幅とは独立して決定される。図１５Ａ、図１５Ｂ及び図１５Ｃを参照すると、スプレッドシート１５００、１５３０、１５７０は、本実施形態に従ったＴＷＩＴＳの使用を示している。

スプレッドシート１５００における表１５０５の提示は、いくつかの方法で改善することができる。まず、ＩＤ列１５１０は、表の外側のシートの部分によって引き伸ばされているため、広すぎる。さらに、譲受人（ａｓｓｉｇｎｅｅ）の名前１５１５は、よりコンパクトに表示することができる。表示を改善するために、表１５０５全体を大きなＴＷＩＴ１５３５として、各行の名と姓のセルをスプレッドシート１５３０に示すように、小さなＴＷＩＴ１５４０、１５４５、１５５０としてレンダリングすることが可能である。

ＴＷＩＴを定義する簡単な方法は、開始／終了セルの各ペアに一意のＴＷＩＴ ＩＤを与えて、ＴＷＩＴ領域が明示的に識別されるようにすることである。しかしながら、これは、名前ＴＷＩＴのように、（おそらく未知の）数のＴＷＩＴを大量に生成する必要がある場合には、面倒なことになりかねない。

その代わりに、本実施形態に従って、ユーザは、どのセルが開始セルであり終了セルであるかを定義することを可能にし、システムは、非交差領域を形成するために開始セルと終了セルを自動的にマッチングさせることができる。スプレッドシート１５３０に示される例では、ユーザは以下の定義を入力することができる。
｀ＩＤ：ＴｗｉｔＢｅｇｉｎ （１３）
ＧｏＳＥ（｀ＩＤ）：ＴｗｉｔＥｎｄ （１４）
ＧｒｏｗＳ（｀Ａｓｓｉｇｎｅｅ ｖｖ １）：ＴｗｉｔＢｅｇｉｎ （１５）
ＧｒｏｗＳ（｀Ａｓｓｉｇｎｅｅ ＿｜ １）：ＴｗｉｔＥｎｄ （１６）

式｀ＩＤは、文字列「ＩＤ」を含むセルの位置を特定する。「ＧｒｏｗＳ（ａ）」は、セルａだけを含む領域から始まり、そのすぐ下のセルが全て空白になるまで、下へと拡張し続ける。したがって、「ＧｒｏｗＳ（｀Ａｓｓｉｇｎｅｅ ｖｖ １）」は、文字列「Ａｓｓｉｇｎｅｅ」を含むセルの直下から始まり、最初の空白セルに出会うまで下に拡張する。同様に、「ＧｒｏｗＳＥ（ａ）」は、セルａを含む領域から始まり、右と下に領域を拡張し続け、すぐ右、すぐ下、すぐ右下に空白で完全に縁取られた表に成長させる。「ＧｏＳＥ（ａ）」は、「ＧｒｏｗＳＥ（ａ）」の右下隅である。これらは、ラベル位置式の例である。

「ＧｒｏｗＳ（｀Ａｓｓｉｇｎｅｅ ｖｖ １）：ＴｗｉｔＢｅｇｉｎ」の定義（１５）は、Ａｓｓｉｇｎｅｅセルの下の全てのセルをＴｗｉｔＢｅｇｉｎセルとしてマークする。「ＧｒｏｗＳ（｀Ａｓｓｉｇｎｅｅ ＿｜１）：ＴｗｉｔＥｎｄ」の定義（１６）は、Ａｓｓｉｇｎｅｅセルの下の最後の列の全てのセルをＴｗｉｔＥｎｄとしてマークする。定義（１３）、（１４）、（１５）、及び（１６）の割り当ての結果を、表１５７０の表１５７５に示す（図１５Ｃ）。

さらに本実施形態によれば、非交差領域は、完全に不連続である領域、又はそれらの境界が交差しないように他の中に完全に含まれる領域のいずれかとして定義することができる。開始セルと終了セルのセットは、非交差領域に対応する最大１つのマッチングを認めることができ、そのようなマッチングは、開始セルの数をｎとすると、「Ｏ（ｎ ｌｏｇ ｎ）」時間で見い出せることを示すことができる。したがって、これらのＴｗｉｔＢｅｇｉｎタグ及びＴｗｉｔＥｎｄタグから、ユーザの意図するＴＷＩＴを常に復元することができる。

あるいは、ＴｗｉｔＢｅｇｉｎタグ又はＴｗｉｔＥｎｄタグの一部をＩＤで補強することも可能である。ＴｗｉｔＢｅｇｉｎタグとＴｗｉｔＥｎｄタグのペアは、それぞれ同じＩＤを有する必要がある。これにより、ユーザはペアリングを明示的に指定することができる。しかしながら、自動マッチングアルゴリズムでは、そのようなＩＤは、一意である必要はない。このように、どのセルが開始タグを有し、どのセルが終了タグを有するかを示すことによって、本実施形態によるフラットな２Ｄスプレッドシート構造において階層的領域を作成することができるが、開始セルと終了セルとの明示的かつ正確なマッチングはなく、したがって、システムは、交差しない領域のセットを生成する開始タグと終了タグとの一意のペアリングを選択する。

シートが多数の行を含む場合、行の挿入と削除は、その下の全ての行に影響するため、非常に高価になる可能性がある。行と列の効率的な挿入と削除は、問題を軽減するためにビグナム（ｂｉｇｎｕｍ）行番号の導入により緩和される。ビグナムとは、任意に高い精度を有する数であるので、二進数で正確に表現できる全ての数を正確に表現できる。

本実施形態によれば、行番号は必ずしも連続である必要はなく、小数であってもよく、整数はスキップすることができる。例えば、１、２、３、４、５行から始まり、ユーザが３行目を削除し、１と２の間に別の行を挿入すると、行番号は、１、１．５、２、４、５となる。このように、行を削除することは、安価な操作であり、その下の行に不必要に影響を与えない。

ビグナム行では、２つの行の順序はまだ決定できるものの、特定の行の前の行又は次の行を決定することは、もはや自明なことではない。（ｉ）ある行ｒの上又は下のｎ番目の行は何か、（ｉｉ）行ｒ１とｒ２の間の距離は何か、という２つのクエリに答えるのに役立つインデックスが必要である。

インデックスは、このようなクエリに効率的に答えられるようにする必要があるが、さらに、インデックスを小さな情報の断片に分解し、セルの計算中に、どの情報の断片が使われたかを記録できるようにする必要がある。そうすれば、ある情報が変化したときに、どのセルを再計算すればよいかが分かる。また、行が挿入／削除されると、そのような情報の一部のみが変更され、そのような情報のリストは容易に見つけることができる。その後、理想的には、本当に再計算が必要なセルだけが再計算される。

この目的のために、本実施形態によれば、スキップリストのような構造が使用される。具体的には、新しい行が作成されるとき、その行には、ランダムにレベルが割り当てられる。行は、レベル１である確率は０．５、レベル２である確率は０．２５、等である。行番号のレベルが変わることはない。また、各レベル１ノードには次のレベル１ノードが記録され、各レベル２ノードには次のレベル１ノードと次のレベル２ノードが記録される。さらに、一般に、レベルＮのノードには、レベル１からレベルＮまでのＮ個の次のノードが記録される。最後に、特別な、目に見えない、一番上の行には行番号「－ｉｎｆ」が割り当てられ、全てのレベルにあるとみなされる。

このように、レベル１は、全ての行のリンクリストを形成する。より高いレベルは、エクスプレスレーンであり、より大きなスパンでの検索をより高速に進めることができる。このインデックスがあることで、「ある行ｒの上／下のｎ番目の行は何か」といった質問には、「Ｏ（ｌｏｇ（Ｎ））」の情報片を使って答えることができる。さらに、「ｒ１行とｒ２行の間の距離は？」という質問にも「Ｏ（ｌｏｇ（Ｎ））」個の情報片を使って答えることができる。

このように、本実施形態によれば、行が挿入又は削除されると、各レベルにおいて、せいぜい２つのリンクに影響を与えることが分かる。したがって、行の挿入又は削除は、せいぜい「Ｏ（レベルの数）」個の情報を破壊する。

ユーザへの提示のために、ビグナム行番号を直接表示しないことを選択してもよいが、むしろ、最初の行までの距離が表示されるので、ユーザは依然として連続した整数を見ることができる。上述したように、２つの行の間の距離は、スキップリストを使用して効率的に計算することができる。

このように、本実施形態は、スプレッドシートの利用及び操作を強化する、堅牢なユーザ向けスプレッドシートプログラミング言語を提供することが分かる。本実施形態によれば、スピル、関数呼び出しとしてのシート置換、セル値及びコールバックパラメータとしてのシート置換（サンク）、バリア、プログラムスタイル定義、ＴＷＩＴ、クラスス（ｃｌａｓｓｓ）、ラベル位置式、リモートコールバックとしてのシート置換（サンク）、コラボレティブ文書におけるきめの細かい許可、シート置換を使用するウェブページ、単一のスプレッドシートによって定義される動的ウェブページ、ユーザ指定制約、空間インデックス、持続的インデックス及びデルタ更新セル、ビグナム行及び列番号、並びに行及び列インデックスが定義されて、簡単で柔軟で汎用性のある下位互換性があり、スプレッドシートフレンドリーなソリューションが提供された。

本実施形態の前述の詳細な説明において例示的な実施形態が提示されたが、膨大な数の変形が存在することが理解されるべきである。さらに、例示的な実施形態は例示に過ぎず、本発明の範囲、適用性、動作、又は構成を何ら制限することを意図していないことを理解されたい。むしろ、前述の詳細な説明は、本発明の例示的な実施形態を実施するための便利なロードマップを当業者に提供し、添付の請求項に規定される本発明の範囲から逸脱することなく、例示的な実施形態に記載されたステップの機能及び配置並びに動作方法において、様々な変更を行うことができることが理解されよう。

Claims (42)

1. スプレッドシートをプログラミングするための方法であって、
   スプレッドシートのセルにラベルを割り当てるステップであって、前記ラベルのそれぞれは、変数の複数の値に対応するデータのための複数の隣接する変数値セルのうちの１つに割り当てられ、前記複数の隣接する変数値セルは、前記複数の隣接する変数値セルのセル範囲の開始及び終了を示すラベルのペアによってユーザ定義される、ステップと、
   定義された式を有するセルから、前記変数の前記複数の値によって定義される変数範囲を含む前記式に応答して、データが流れ込むことができるスピルエリアを定義するステップであって、前記スピルエリアが前記変数の前記複数の値に対応する複数の式解に自動的にサイズ調整される、ステップと、
   を含む、方法。
2. スピルエリアを定義するステップが、前記複数の隣接する変数値セルへのデータの後続のユーザ入力の前に、定義された式を有するセルからデータが流れ込むことができる非縮小スピルエリアを定義することを含む、請求項１に記載の方法。
3. 前記スピルエリアに弾性限界を確立するために１つ以上のセルにわたってバリアを定義するステップをさらに含み、前記スピルエリアを定義するステップは、前記複数の隣接する可変値セルに入力されたデータが前記スピルエリア内のセルの数より大きい複数の式解に対応するとき、前記バリアに隣接する前記スプレッドシートの残りの部分を妨げることなく、弾性スピルエリア内のセルを定義するステップを含む、請求項１に記載の方法。
4. １つ以上のセルに渡ってバリアを定義するステップは、前記スプレッドシートの行又は列の全てのセルにわたってバリアを定義するステップを含む、請求項３に記載の方法。
5. 前記スプレッドシートの大きな表の内部に１つ以上のミニ表を囲む１つ以上の表内表（ＴＷＩＴ）を定義するステップをさらに含み、前記１つ以上のミニ表のそれぞれが占める行の数、列の数及び総面積は、ユーザＴＷＩＴ入力に応答して定義される、請求項１～４のいずれか一項に記載の方法。
6. 前記スプレッドシートの前記大きな表の内部の前記ミニ表は、少なくとも２つの非交差領域を備える、請求項５に記載の方法。
7. 前記ユーザＴＷＩＴ入力が、１つ以上のセルをＴＷＩＴ開始セルとして指定し、１つ以上のセルをＴＷＩＴ終了セルとして指定するステップを含み、前記スプレッドシートの前記大きな表の内部に前記ミニ表を囲む前記ＴＷＩＴを定義するステップが、前記１つ以上のＴＷＩＴ開始セル及び前記１つ以上のＴＷＩＴ終了セルに応じて、前記１つ以上のミニ表のそれぞれが占める行、列及び総面積を定義するステップを含む、請求項５又は請求項６に記載の方法。
8. 前記１つ以上のＴＷＩＴ開始セルのうちの少なくとも１つ及び前記１つ以上のＴＷＩＴ終了セルのうちの対応する少なくとも１つは、ＴＷＩＴペアリングＩＤを含む、請求項６に記載の方法。
9. 曖昧さが、前記ＴＷＩＴペアリングＩＤの不在によって、又は同じＴＷＩＴペアリングＩＤを含む前記１つ以上のＴＷＩＴ開始セルのうちの２つによって、又は同じＴＷＩＴペアリングＩＤを含む前記１つ以上のＴＷＩＴ終了セルのうちの２つによって定義され、前記方法が、ＴＷＩＴ境界の交差を認めないことによって前記曖昧さを解決するステップをさらに含む、請求項７又は請求項８に記載の方法。
10. ユーザがプログラム可能な二次元スタイル定義に従って前記スプレッドシートのセルを表示するステップを含む、請求項１～９のいずれか一項に記載の方法。
11. 前記ユーザがプログラム可能な二次元スタイル定義が、データフォントスタイル、データフォント色、及びセル背景色のうちの１つ以上を含む、請求項１０に記載の方法。
12. スプレッドシートプログラミングのための方法であって、スプレッドシートに別のアイテムを、関数呼び出し及び／又はリモートコールバックを含む前記スプレッドシートのセルのセル値に応答して置換するステップを含む、方法。
13. 前記スプレッドシートに置換された前記アイテムの形状が、前記セルの元の値の形状と一致しない場合に、エラーが発生する、請求項１２に記載の方法。
14. 前記スプレッドシートに前記別のアイテムを置換するステップが、前記スプレッドシートのセルの値に応答して、動的に指定されたスプレッドシート参照を前記スプレッドシートに置換するステップを含み、前記動的に指定されたスプレッドシート参照が、動的に指定されたディレクトリ参照及び別のスプレッドシートのスプレッドシート名を含む、請求項１２に記載の方法。
15. 前記スプレッドシートのセルにおける読み取り及び／又は書き込みコードへのアクセスが、きめ細かいアクセス制御許可に従って制御され、前記きめ細かいアクセス制御許可が、具象ユーザ及び抽象ユーザのうちの１つ以上に従って定義されたシート所有者及びシートユーザを含む、請求項１～１４のいずれか一項に記載の方法。
16. 前記ラベルを操作するためのラベル位置式を定義するステップをさらに含み、前記ラベル位置式は、前記ラベルが割り当てられている前記セルの座標を操作する、請求項１～１５のいずれか一項に記載の方法。
17. 二次元配列に配置された複数のセルであって、前記複数のセルのうちの１つ以上が、前記スプレッドシートに別のアイテムを置換するためのセル値を含み、前記セル値が関数呼び出し及び／又はリモートコールバックを含む、複数のセルを含む、スプレッドシート。
18. 動的に指定されたスプレッドシート参照が、前記セル値に応答して前記スプレッドシートに置換され、前記動的に指定されたスプレッドシート参照が動的に指定されたディレクトリ参照及び別のスプレッドシートのスプレッドシート名を含む、請求項１７に記載のスプレッドシート。
19. 二次元配列に配置された複数のセルであって、前記複数のセルが、変数の複数の値に対応するデータのための複数の隣接する変数値セルを含み、前記複数の隣接する変数値セルが、前記複数の隣接する変数値セルのセル範囲の開始及び終了を示すセル値のペアによってユーザ定義される、複数のセル
    を含む、スプレッドシートであって、
    前記複数のセルが、前記変数の前記複数の値によって定義される変数範囲を含む式に応答して、定義された式を有するセルからデータが流れ込むことができるスピルエリアをさらに備え、前記スピルエリアは、前記変数の前記複数の値に対応する複数の式解に自動的にサイズ調整される、スプレッドシート。
20. 前記スピルエリアは、前記複数の隣接する変数値セルへのデータの後続のユーザ入力の前に、定義された式を有するセルからデータが流れ込むことができる非縮小スピルエリアを含む、請求項１９に記載のスプレッドシート。
21. 前記スピルエリアに弾性限界を確立するために１つ以上のセルにわたってバリアが定義され、前記スピルエリアは、前記複数の隣接する可変値セルに入力されたデータが前記スピルエリア内のセルの数より大きい複数の式解に対応するとき、前記バリアに隣接する前記スプレッドシートの残りの部分を妨げることなく、弾性スピルエリア内にあるように定義されたセルを含む、請求項１９によるスプレッドシート。
22. 前記バリアが前記スプレッドシートの行の全セル又は列の全てのセルにわたって定義される、請求項２１に記載のスプレッドシート。
23. 前記スプレッドシートのセルにおける読み取り及び／又は書き込みコードへのアクセスが、きめ細かいアクセス制御許可に従って制御され、前記きめ細かいアクセス制御許可が、具象ユーザ及び抽象ユーザのうちの１つ以上に従って定義されたシート所有者及びシートユーザを含む、請求項１７～２２のいずれか一項に記載のスプレッドシート。
24. 前記複数のセルが、前記スプレッドシートの大きな表の内部の第一のミニ表を囲む第一の表内表（ＴＷＩＴ）を含み、前記第一のミニ表が占める行の数、列の数及び総面積が、ユーザＴＷＩＴ入力に応答して定義される、請求項１７～２３までのいずれか一項に記載のスプレッドシート。
25. 前記複数のセルが、前記スプレッドシートの前記大きな表の内部の第二のミニ表を囲む第二のＴＷＩＴを含み、前記第一のミニ表と前記第二のミニ表とが、前記スプレッドシートの前記大きな表内で非交差領域を含む、請求項２４に記載のスプレッドシート。
26. 前記ユーザＴＷＩＴ入力が、１つ以上のセルをＴＷＩＴ開始セルとして指定する開始セル定義と、１つ以上のセルをＴＷＩＴ終了セルとして指定する終了セル定義を含み、前記第一のミニ表が占める前記行と前記列を定義する、請求項２４又は請求項２５に記載のスプレッドシート。
27. 前記ＴＷＩＴ開始セルの少なくとも１つと前記ＴＷＩＴ終了セルの少なくとも１つは、ＴＷＩＴペアリングＩＤを含む、請求項２６に記載のスプレッドシート。
28. 曖昧さが、前記ＴＷＩＴペアリングＩＤの不在によって、又は同じＴＷＩＴペアリングＩＤを含む前記１つ以上のＴＷＩＴ開始セルのうちの２つによって、又は同じＴＷＩＴペアリングＩＤを含む前記１つ以上のＴＷＩＴ終了セルのうちの２つによって定義され、方法が、ＴＷＩＴ境界の交差を認めないことによって自動的に解決される、請求項２７に記載のスプレッドシート。
29. 前記複数のセルのうちの１つ以上は、セルを表示するための１つ以上のユーザプログラム可能な二次元スタイル定義を含む、請求項１７～２８のいずれか一項に記載のスプレッドシート。
30. 前記ユーザプログラム可能な二次元スタイル定義が、データフォントスタイル、データフォント色、及びセル背景色のうちの１つ以上を含む、請求項２９に記載のスプレッドシート。
31. 前記複数の隣接する可変値セルの１つ以上のセルが、それに割り当てられたラベルによってユーザ定義され、ラベル位置式が、前記二次元配列内の前記複数の隣接する可変値セルの前記１つ以上のセルの座標に応答して、前記ラベルに作用する、請求項１９～３０のいずれか一項に記載のスプレッドシート。
32. 動的ウェブサイトのプレゼンテーションのための方法であって、
    単一のスプレッドシート文書に応答して前記動的ウェブサイトの前記プレゼンテーションを生成するステップであって、前記単一のスプレッドシート文書は、データ及びビジネスロジックを含み、前記動的ウェブサイトの前記プレゼンテーションのための前記方法は、前記単一のスプレッドシート文書の前記データ及び前記ビジネスロジックに応答して生成される、ステップ
    を含む、方法。
33. 前記ビジネスロジックが、ユーザ提出データに応答して実行される１つ以上のマクロを含む、請求項３２に記載の方法。
34. 前記動的ウェブサイトの前記プレゼンテーションを生成するステップは、
    動的ウェブページ要求に応答して、動的ウェブページ要求クエリパラメータをスプレッドシートに置換するステップと、
    それに応答して、前記スプレッドシートを前記動的ウェブサイトのウェブページとしてレンダリングするステップと、
    を含む、請求項３２又は請求項３３に記載の方法。
35. 二次元配列に配置された複数のセルであって、前記複数のセルの１つ以上が、非エラー値及び非偽値に評価されるように設計されたユーザ指定制約を含む、複数のセルを含む、スプレッドシート。
36. 前記複数のセルのうちの少なくとも１つに対して実行されたアクションは、前記ユーザ指定制約の１つ以上が失敗する原因となった前記アクションに応答して拒否され、前記スプレッドシートは、前記ユーザ指定制約の１つ以上が失敗する原因となった前記アクションに応答して、前記アクションが実行される前の状態に復元する、請求項３５に記載のスプレッドシート。
37. スプレッドシートをスプレッドシートプログラミングするための方法であって、
    非エラー値及び非偽値に評価されるように設計された制約を含むように、前記スプレッドシートの１つ以上のセルをユーザ指定するステップと、
    前記スプレッドシートの前記１つ以上のセルの少なくとも１つに対してアクションを実行するステップと、
    前記制約の少なくとも１つが失敗する原因となった前記アクションに応答して、前記アクションを拒否するステップと、
    前記制約の少なくとも１つが失敗する原因となった前記アクションに応答して、前記スプレッドシートを前記アクションが実行される前の状態に復元するステップと、 を含む、方法。
38. スプレッドシートのセルの任意のブロックにおける値の検索を高速化する方法であって、
    空間インデックスを利用するステップと、
    可能なセル値の総順序を定義するステップと、
    を含む、方法。
39. 前記空間インデックスがＲ－ｔｒｅｅインデックスを含む、請求項３８に記載の方法。
40. スプレッドシートであって、
    複数の行と複数の列によって定義される二次元配列に配置された複数のセルであって、前記複数の行のそれぞれがビグナム行番号によって識別され、前記複数の列のそれぞれがビグナム列番号によって識別され、各ビグナム行番号と各ビグナム列番号がその二進表現において任意に高い有限精度が可能な数を含む、複数のセルを含む、スプレッドシート。
41. 前記複数の行に１つの行が追加又は削除されたときに、前記複数のセル内のセルの再計算を効率的に行うための行スキップリストをさらに含む、請求項４０に記載のスプレッドシート。
42. 前記複数の列に１つの列が追加又は削除されたときに、前記複数のセル内のセルの再計算を効率的に行うための列スキップリストをさらに含む、請求項４０又は請求項４１に記載のスプレッドシート。

Images