キュー付きカプセル化DOMツリー

CRUD操作のCRは同期、UDは非同期（キューされる）。UDを編集操作と呼ぶ。

例：

• 同期の場合： Node oldChild = node.removeChild(child)
• 編集リクエスト RequestId id = node.requestEdit(REMOVE_CHILD, child)
• 変更イベント childRemoved(id, node, oldChild)

編集メソッドを呼び出す代わりに、対応する編集リクエストを行う。戻り値の代わりに変更イベントを受け取る。addEventListener(type, listener, options) と requestEdit(method, args...) が基本になる。

requestEditで、編集リクエストはキューに置かれる。キューイングした順に実行されるとは限らないが、いずれは実行され、結果はイベントを確認すればわかる。編集が失敗することはある、それはしょうがない。

失敗しないで実行されたリクエストは削除されないで、すべて記録される。編集リクエスト列は、そのまま編集ログになる。よって、無限UNDOが可能となる。パーシステントストレージに保存すれば、過去に起動されたときの実行もUNDOできる。人に分かりやすいUNDO/REDOのインターフェイスは難しい。

Aliceのジャーゴン

• ゾーンと、（文書ツリーの）ゾーン分割
• エディットレット
• エディットレット・チーム
• エディットレット・フォーメーション
• エディットレットの動的ロードとアクティベーション（ファセットのアタッチ）
• ファセットとファセットツリー、ゾーンツリーは別物。
• フォーリンオブジェクトノード〈foreign object node | FONode〉もとはSVG <foreignObject>
• FONodeラッピング＝フォーリンオブジェクトノードによる（フラグメントの）ラッピング
• コネクタ （ゾーンとファセットを双方向に繋ぐ）
• 穴開きキャンバス ゾーンに対応する、穴〈ペイン〉はFONodeに対応
• ペイン ゾーンのFONodeに対応する、CSS的にはFOBox〈foreign object box〉
• エイペックス ゾーンのルートノード キャンバスのルートボックスに対応する
• XHTMLフラグメントは多用される。FONodeの内容〈子ノードリスト〉にXHTMLフラグメントとか。

思いつたから書く： xml:space だけでは空白は制御できない。どう表示するかわからない。インライン属性が付くとは限らないし。

• https://www.atmarkit.co.jp/ait/articles/0102/28/news001.html

続き：

• スキャン＆推測
• 確信のある決定〈confident dispatch〉

http://e-words.jp/w/%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81.html より：

ディスパッチとは、発送（する）、派遣（する）などの意味を持つ英単語で、ITの分野では同種の複数の対象から一つを選び出したり、データの送信、資源の割り当て、機能の呼び出しなどを表すことが多い。

[追記]当時使っていたわけではないが、

• パートナー不可知的〈partner agnostic〉
• パートナー不可知原理〈partner agnostic principle〉
• 無管理チーム〈managementless team〉a team doesn’t need management
• 自動フォーメーション〈automatic formation〉doesn’t need control 仕事の分担、チーム内での役割が自動で決定する。

エディットレットはチームで働くが、事前にパートナー〈チームメイト〉の知識は一切持たない。知っているのは、協業連携するときのネゴシエーション・プロトコルだけ。単独で仕事するときも、チームで仕事するときも、まったく同じ行動をする。

エディットレットはプラグインとして作られるので、プラグインの作り方のお作法さえ守っていれば、他のプラグインと協調動作できなくてはいけない。複数のプラグイン達が、どのように組み合わせられるかは事前に予測できない。
[/追記]

PIとコメントの問題

• PIは処理に対するヒント／設定やメタデータとして機能する可能性がある。ゾーン分割＝色分けのとき、PIノードをどの名前空間（色）に振り分けるかがわからない。
• コメントノードも同様。コメントアウトに使われると、スプライシングで復活したりする。
• 時代的に後だが、「コメント内にRDFメタデータを入れよう」とかろくでもないことを言い出す人がいて、実際にそれが行われてしまった。この場合、文書の一部として重要な情報がコメント内に記述されることになる。RDFはXML構文で書かれているので、コメントノード内のテキストデータをパーズしてDOMツリーにする必要がある。が、コメントノード内にメタデータがあるかどうかは、スキャン＆推測〈scan and guess〉しかない。
• 我々にとって、テキストノード（PIノード、コメントノード含める）内のスキャン＆推測は非常に嫌な作業で、文書内の意味のある情報は要素として書いてほしい。
• コメントノードをアンコメンティング（スプライシング）するときがほんとに嫌で、メタデータ／ヒントが一切ないので、確信が持てないスキャン＆推測で処理するしかない。
• PIターゲット名は、修飾されてない短い名前で、登録機関もない。それでディスパッチするのはリスキー。確信が持てるのは <?xml くらい。
• <?foo xmlns="http://example.com/PI/foo" データ > <?ns:foo xmlns:ns="http://example.com/PI/foo" データ > として欲しかった。
• 確信のあるディスパッチ〈confident dispatch〉（選択、決定）をしたかった。
• だから、過激な名前空間推進派だった。

ツリーの基礎知識

ノードの識別：

1. IDによるノード識別 t#ID
2. 単純ロケーションパスによるノード識別 t/n₁/n₂ ... /n_k
3. ツリーオーダー・インデキシングによるノード識別 t[i]

位置 ℓ をノード識別子（ID、ロケーションパス、ツリーオーダー・インデックス）として

1. ℓ(<) ℓの直前（多くの場合は左隣）の位置
2. ℓ(>) ℓの直後（多くの場合は右隣）の位置
3. ℓ(j) （jは1以上の整数）
   1. j = 0 のとき 1番目（最初）の子の直前の位置
   2. その他のとき、j番目の子の直後の位置

AutoHotKey パススルー

キー設定で右辺を書かない。

^c::

Alice基本概念

文書ツリー	レンダリング先空間	ソフトウェアコンポネント
ゾーン	キャンバス	エディットレット
子ゾーン	ペインと子キャンバス	パートナー・エディットレット

擬人化による比喩：

• エディットレット（得意分野を持った作業員）
• エディットレットチーム（文書編集業務を担当する作業チーム）
• エディットレットフォーメーション（どのような作業分担体制で仕事に挑むか）
• 無管理チーム〈managementless team〉： 管理者やチームリーダーはいない。それぞれが、自分の仕事をこなすだけで連携プレーが出来てしまう。
• フォーメーションが、対象文書から自動的に決定される。→ゾーン分割アルゴリズムとエディットレットのケイパビリティ（シングルゾーン、マルチゾーン）で決まる。マルチゾーン・エディットレットは未実装だった？
• 肝はネゴシエーション・プロトコル
• ゾーンの担当は、一人のメジャー・エディットレットと複数のマイナー・エディットレット。

ハイブリッド文書とは、例示：

• 全体はXHTML
• 化学式はCML → https://en.wikipedia.org/wiki/Chemical_Markup_Language
• メタデータはダブリンコア → https://ja.wikipedia.org/wiki/Dublin_Core#%E5%9F%BA%E6%9C%AC%E8%A8%98%E8%BF%B0%E8%A6%81%E7%B4%A0%E4%B8%80%E8%A6%A7 基本記述要素一覧
• 図はSVG
• 数式はMathML （数式編集は別途、問題ではある！）

前と後ろ？

カーソルと削除キーの話で、ABC|DEF で、縦棒が文字カーソル〈カレット〉だとする。

• BSはカーソルの前の文字（例のC）を消す
• Delはカーソルの後の文字（例のD）を消す

ウーン、カーソルが左から右で進行するから、カーソルに乗り移って考えると、「Dが自分の前にあり、Cが自分の後ろにある」と感じる。行頭（Aの左）の位置に人がいるとすると、その人からはCが前（より自分に近い）、Dが後（自分から）遠い。と思える。

前、後も主観で違う！ ところで、Ctrl+H って、標準的には置換だったのか。

IMEキーと便利技

• Compositionモードで、ConvertToHalfAlphanumeric のトグルで小文字大文字先頭大文字となる。便利。

カーソル移動：

1. Composition MoveCursorLeft
2. Composition MoveCursorRight
3. Composition MoveCursorToBeginning
4. Composition MoveCursorToEnd

セグメント操作：

1. Conversion SegmentWidthShrink
2. Conversion SegmentWidthExpand
3. Conversion SegmentFocusLeft
4. Conversion SegmentFocusRight
5. Conversion SegmentFocusFirst
6. Conversion SegmentFocusLast
7. Conversion CommitOnlyFirstSegment

ウギャー、キーマップは地獄だ

AutoHotKeyを使ってグローバルに周縁キー（ホームポジションから遠いキー）を Ctrl+ナントカ に割り当てることにした。カーソル移動や文字削除ね。

VSCodeの C-x C-f キーの2ストローク目がAutoHotKeyで変換されてしまう。AutoHotKeyが2ストローク目を認識するのは難しい。

それと、EmacsがHenkanキーを見てしまう問題は解決されたようだ。IMEOn状態でもhenkanキー設定をしたのが良かったのかな？

積分の書き方

• 
• 

正確には：

ラベルとアイテム

ドキュメントツリーのノードの種類〈kind〉を次のようにする。

• アイテムノード（IDを持つノード）
  • セクションノード
  • ブロックノード
  • インラインノード
• フラグメントノード
• その他、アイテム以外のノード

ラベル空間はIDも含むラベルの集合だから、ident:Item→Label という写像がある。Item ident(Item)。Labelのなかで、 単値ラベルの集合がある。それをSVLabelとする。refl:SVLabel→Item も写像になる。 refl:Label→Item は写像ではない。

• ident:Item→Label 写像
• refl:Label→Item 関係
• point = refl :SVLabel→Item 部分写像
• refl^†:Item→Label 反転関係
• point^†:Item→SVLabel 反転関係

Powershellの文字エンコーディング

Powershellのコンソール入出力の標準utf-8は、utf-8LE なのか？

ラベリングシステム

ラベルの種類

1. ターゲット多重度： 1, *, +, ?(0 | 1), 0
2. ターゲットカインド： section, block, fragment, range,textrange(term)
3. 接頭辞： あり、なし 例： foo, a:foo
4. セグメント： ひとつ、複数 例： foo>bar, bar>foo

コンポネントと機能

コンポネント、アスタリスクはオプショナル。

1. サーバー
2. * コンパイラ
3. * 逆コンパイラ
4. * 原稿エディタ（クライアント）
5. ドキュメントエディタ（クライアント）
6. ドキュメントビューワー（クライアント）
7. * ドキュメントコンバーター

形式と変換

1. * 原稿形式
2. サーバーネイティブ形式
3. コンパイラ : 原稿形式 → サーバーネイティブ形式
4. 逆コンパイラ : サーバーネイティブ形式 → 原稿形式

サーバーの機能

1. ドキュメントツリーへのアクセス提供
2. ラベリングシステムへのアクセス提供

ラベリングシステムのサービス

1. ラベルの存在確認
2. ラベルの特性を知る
3. ラベルQLによる問い合わせ
4. ラベルからターゲット〈リファレント〉取得

一番重要なのはラベリングシステム。

日記：今日のキースワップ 0719

1. CapsLoc → 左Ctrl 絶対必須
2. 変換 → 半角/全角 ほぼ必須
3. 右Alt → 右Ctrl あまり意味がないようだ
4. 左Ctrl → Esc けっこういい
5. 半角/全角 → 変換 入れ替えたみた

以下はママ。

1. 無変換 AutoHotKeyでハイパーキーにする
2. カタカナひらがな/ローマ字 普通に使う
3. 右Ctrl 普通に使う