Xyndy .jp

コンテナエディターと見出しエディター

コンテナエディターと見出しエディター。2つの違いは、同じ文書に両方を適用してみると分かるか、と。

例えば、次の文書(URL)で試してみます:

Softwears
http://www.yamahige.jp/softwares/index.html
# ね、こういうときに、手近な素材に走るんですよね…

1. まず見出しエディターを適用します: ボキャブラリーコンポーネントを見出しエディターにします。
2. 次ぎに、右ペインにカーソルを置いて、コンテナエディターを適用します。

3. コンテナエディターの表示設定を次のようにします。「コンテナエディター」メニューから「表示」を選んで、次のように「ラベルに表示する要素名の一部を記号で」と「コンテナと見出しのみを表示」だけにチェック(v)が入るようにします。

   •  ラベルにクラス名を表示
   • v ラベルに表示する要素名の一部を記号で
   •  ラベルにIDを表示
   • ----------
   •  選択されたときに属性を表示
   • ----------
   • v コンテナと見出しのみを表示
4. すると、こんな風に見えます…。

>>大きい図

見出しエディターでは、見出しに目次風のインデントがついて表示されます。こんな感じ:

• § Softwears
• • § EUREKA
  • • § STORYWRITER
    • § Template It!

コンテナエディターでは、同じ部分がこのように表示されてますね:

• § Softwears
• § EUREKA
• § STORYWRITER
• § Template It!

コンテナ(div要素)は、文書を構成する要素を様々にグルーピングするために使われます。章節構成もその1つでしょう。

しかし、コンテナで章節をグルーピングしなくても、見出しを大きくしたりして区別すれば、人には章節の構成が見えます。ワープロがそうですね。

見出しエディターは、コンテナによるグルーピングにかかわらず、見出しだけに基づいて章節構成を表示し、章の入れ替えなどの編集を可能にしています。上の例の文書は、章節の構成にコンテナを使っていませんが、それにもかかわらず、章節構成をインデントで示しています。

普通はコンテナを使いません、というか知りませんから、見出しエディターだけで十分だと思います。

グルーピング

「章節以外に、どんなグルーピングがあるんだ？」

例えば、ブログの段組や記事(エントリー)はコンテナ(div要素)を使ってグルーピングされています。コンテナ(div要素)なしに、現代のWebはありません。

次の例では、スライド表示する部分を、コンテナを使ってグルーピングしています:

定性的で主観的で個人的な記録を活用するシステムの試作 ～ 時間情報を例に
http://www.yamahige.jp/documents/2008-07-24_SigDD_67/20080725-SigDD-67_v2_20080727.html

コンテナエディターの表示を次のようにします:

• v ラベルにクラス名を表示
• v ラベルに表示する要素名の一部を記号で
•  ラベルにIDを表示
• ----------
•  選択されたときに属性を表示
• ----------
•  コンテナと見出しのみを表示

スライド表示する部分は、slideというクラスのコンテナでグルーピングされています。

# 中身がslideというコンテナに属するんですよ、という意味で∋を使ってます。

つづく…

コンテナエディターを公開しました。ここで報告する前に修正が入って、0.3.1です。

コンテナ(div要素)は、要素をグルーピングするのに使われます。わたしもよく使います。でも、WYSIWYG編集では、その存在が見えにくい。いくつか階層が重なると、選択して、クラス設定を変えて…という操作がまどろっこしい。そういうときは、WYSIWYGよりも、昔ながらのXMLエディターのようなツリー型で編集したくなります。

用途はこんなところ:

• 対訳エディタの編集機能不足を補う (^_^;
• xfy Personal Clientのストックを使って、ストックを文書に挿入するときのドラッグ&ドロップターゲットにする。
• 見出しエディターと使い分ける。

初めはブロックエディターと呼んでましたが、XHTMLコンポーネントでは、「囲む」操作が「コンテナ」と結びついているので、コンテナエディターと呼ぶことに。

アウトラインエディターか？

1年ちょっと前に見出しエディターを -- 当時はHeading Operatorと呼んでいた -- アウトラインエディターと呼ばなかった理由は2つ:

1つは、これが頭にあったから。見出しエディター、コンテナエディター、どちらかをアウトラインエディターと呼んでしまったら、もう一方の名前に困るだろう、と。

もう1つは、見出しの並びや章節の階層構造だけが、文章のアウトライン -- 概略、概要 -- ではないだろう、ということ。アウトラインを、なんらかの《構成》、《構造》を指すものだと限定しても。例えば『藪の中』のアウトラインは、STORYWRITER 2が示すようなものではないか。

昨年の7月に「Heading Operator」として公開したものを改訂して、「見出しエディター 0.3.1」として公開しました。

特に、これという大きな修正はしてません。ただ、自身を2ペインにしたり、見出しの文字が修正できたりと、これまで自分で使ってて、少しずつ溜めてた改善を反映しました。

CrossConceptをXHTMLベースにすると宣言したのが2月、はや6ヶ月、…まだできてません。仕様を決められない。時間がとれない。

これまでのCrossConceptは、コンセプトを示すツールとしては役割を果たしてると思う。1つで、あれこれ様々な可能性を示せる。でも、そのぶん抽象的すぎる。せめて、「箇条書きと連動する表エディター」くらいにはしないと。

データ構造は、当初はhAtom方式を考えていました。今は、いわば「Table rendering by non-visual user agents」方式で実装を進めてます。

hAtom方式

もともとAtomに準じて設計していたので、hAtomに倣えばよいと。

Table rendering by non-visual user agents方式

th要素、td要素のscope属性、headers属性、axis属性を使えば、所望のデータ構造を表現できるのではないか…？

次のようなCrossConceptの表を例に、検討の過程をダイジェストしてみます。

hAtom方式

hAtom方式では、表のセルに表示される内容は、例えば次のように表現するのだろうな:

<ul id="target">
 <li id="CIO">…</li>
 <li id="WD">Webデザイナー</li>
 <li id="OFFICE">…</li>
</ul>

<div class="hentry">
 <h3 class="entry-title">◎</h3>
  <div class="entry-content">
   <p>とても適した演題になるでしょう。</p>
  </div>
  <p>Related to: <a rel="bookmark" href="#WD">Webデザイナー</a></p>
  <p>Related to: <a rel="bookmark" href="#Web20">Web 2.0</a></p>
</div>

これを解釈して、CrossConceptが上図のような表として表示します。

…つまり、これだと、CrossConceptが表形式で表示しているコンセプト間の関係が、通常のブラウザ上では表形式では見えない。それはいやだ。

じゃぁ、最初から表にしてしまえばよいのでは？次はどうか？

<td class="hentry">
 <h3 class="entry-title">◎</h3>
  <div class="entry-content">
   <p>とても適した演題になるでしょう。</p>
  </div>
  <p>Related to: <a rel="bookmark" href="#WD">Webデザイナー</a></p>
  <p>Related to: <a rel="bookmark" href="#Web20">Web 2.0</a></p>
</td>

これだと、<a rel="bookmark" href="#WD">Webデザイナー</a>の邪魔さが際だつ。

でも、もう表になってるんだから、対応する見出しを指すリンクは不要なんじゃないの？これでどう？

<td class="hentry">
 <h3 class="entry-title">◎</h3>
  <div class="entry-content">
   <p>とても適した演題になるでしょう。</p>
  </div>
</td>

いや、リンクは必要。リストから「Webデザイナー」という項目を削除したら、連動して表の列を削除できなくては…。

Table rendering by non-visual user agents方式

HTML 4.01の「11.4 Table rendering by non-visual user agents」は、まるでCrossConceptのために書かれたかのよう。CrossConceptは、思いっきりvisualなuser agentだけど。「non-visual user agents」を「CrossConcept」に置き換えて読むと、scope属性、headers属性、axis属性を使うのが正しいと思えます。

<ul id="target">
 <li id="CIO">…</li>
 <li id="WD">Webデザイナー</li>
 <li id="OFFICE">…</li>
</ul>

<th id="TH-WD" axis="target">
 <a href="#WD">Webデザイナー</a>
</th>

<td headers="TH-WD TH-Web20">
 <p>◎</p>
 <p>とても適した演題になるでしょう。</p>
</td>

headers属性はIDREF型なのですね、HTML唯一の。

axis属性も実は同様なのかも。CrossConceptはこれを、カンマ区切りのIDREFもどきとして扱うことにします。

HTML 4.01では次のようになっているので、この扱い方はCrossConcept固有のモノとなりますが、規格違反にはならないでしょう。

• axis = cdata [CI]。つまりcase-insensitive
• The value of this attribute is a comma-separated list of category names.
• This specification does not require user agents to handle information provided by the axis attribute, nor does it make any recommendations about how user agents may present axis information to users or how users may query the user agent about this information.

HTML 4.01のaxis属性が、大文字小文字を区別せず、また区切りにカンマを使うのは、speech synthesizersが読み上げることを想定しているから、かも。

要求定義と暗黙的に知る過程

こうして検討する過程で、自分がCrossConceptを何だと思っているのかが分かってきます。これを外したらCrossConceptじゃなくなる、そういうものは何か？

また、CrossConceptを日常的に使ううちに感じるもどかしさを整理してみると、XHTMLベースに移行することで達成したいことも見えてきました。

• CrossConceptで表に見えるモノは、ブラウザでも表に見せたい。印刷も任せたい。
• 素のXHTMLのリストと表から、CrossConcept用の構造を構築できるようにしたい。

ところで…、ここで、少し話題を変えます。

データ構造が決まるとき、別の何かも決まるのですね。同時進行で、寄り添うように決まる。でも、両者の論理的な関係は、後者の「別の何か」を前提にして前者の「データ構造」が決まる、というものです。「別の何か」が「データ構造」の副産物であるとか、副次的であるとかいうのは違う気がします。

このような「決めごと」「知ること」の構造を踏まえて、来週、「知識再利用システムならびにその展開」という企画セッションでお話しする予定です。

第67回デジタルドキュメント研究会で発表しました:

発表資料をこちらに置いておきます:

定性的で主観的で個人的な記録を活用するシステムの試作 ～ 時間情報を例に
http://www.yamahige.jp/documents/2008-07-24_SigDD_67/20080725-SigDD-67_v2_20080727.html

STORYWRITER 2というのを作りました。公開は、まだ先になると思います。

対訳エディターを改訂しました:

タグダイレクト機能はATOKを使って用語を挿入するため。Lynx Retrieverは用語の用法の整合性を見るのが目的です。

機能を統合して使う

自慢。

Firefoxで拡張機能をアドオンするようなものですね。これを用途・目的別にやる、と。

もともと対訳エディターもLynx RetrieverもタグダイレクトもXHTML文書を対象にしているので、何もしなくても同じ1つの文書に対してこれら機能を使うことができます。

でも、より使いやすくなるように、対訳エディターの並行表示ビューに機能を統合しています。それぞれ、対象とするソースボキャブラリーはXHTMLと同じですが、各機能はそれぞれ固有の名前空間の基に実装しています。なので、わりとあっさりと統合できます。

具体的には、テンプレート(xvcd:template要素)には、それぞれ固有のmode属性を付けているし、コマンド(xvcd:command)や関数(xvcd:function)も固有の名前空間に属しています。このため、衝突する心配がありません。xvcd:importするスクリプトファイルを切り替えたりして、機能を上書きすることもやってます…これはちょっと危険(^_^;

xfy Basic Edition限定で、xfy Blog Editorでは使えませんが、逆変換もできるようにしました。

ひとことで「タグダイレクトはタグを直接入力する機能」と言ってますが、実際は「タグ付きテキストを要素などに変換してカーソル位置に挿入する機能」です。挿入するのは要素などであってタグではありません。だから、タグダイレクトを使ってある場所に開始タグ<em>を挿入して、次に別の場所に終了タグを</em>を挿入して、既存の内容をem要素の内容とする、ということはできません。

でも、そういうことをしたくなる気持ちは分かるので、実装したのがこれ、逆変換。修正したい範囲を、まずタグ付きテキストに戻して、それから開始タグ<em>を書き、次に別の場所に…とやれば、既存の内容をem要素の内容とする、ということができますね、と。

まるで外科手術をしてるよう。なので、UIもそれっぽくしてみました。ヤバイので、歯止めをかけて、ブロック要素はいじれないようにしています。

また一歩、やってはならないことに足を踏み込んでしまった気がする。限りなくしている。

Lynx Retrieverを改訂しました:

文書の整合性や構成

自分のを実験台にします。例えば、次のプレゼン資料「文書内容の操作に見るマークアップの効果 - 解説 -」で使われている「通常の意味の文書」ということばの用法を見てみます。

1. まず、Lynx Retrieverをxfy Basic Editionにセットアップします。
2. URL「http://www.yamahige.jp/documents/2008-06-06_SigDD_66/20080606-SigDD-66_v3_20080704.html#term-ordinary」をコピーして、xfy Basic EditionのブラウズバーのURL欄に貼り付けて開くと、「通常の意味の文書」を説明した…と著者が思ってる箇所が表示されます。
3. ボキャブラリーコンポーネントを「Lynx Retriever」に変えます。
4. さっきの部分に⇒]が表示されています。ここをクリックします。
5. すると、この部分へリンクしている、つまりこの部分を参照している6箇所が表示されます。これらは、文書内に登場する順番に並んでいます。
6. 各部分の左側の[+]をクリックすると、そこに引き寄せて表示する範囲が広がります。[-]をクリックすると狭まります。右肩の[x]をクリックすると、引き寄せた全体が消えます。

で、どうすかね…。こうして見ると、「通常の意味の文書」という概念がまだまだすんなりとは呑み込めない気がします。それは、「通常の意味の文書とは、○○である。」という直接的な書き方をしてる部分がないから、かもしれません。この書きっぷりを良しとするかしないか…。

…ってなことを、検討する役に立てるためのツールなんです、Lynx Retriever。

つまり整合性といっても、数字が合ってるか？とか、リテラルに同じ内容を機械的にリンク挿入するとか、そういう整合性ではありません。もちろん、それはそれで重要な整合性です。ここでは、意味的な整合性をさしています。

また、内容の構成といっても、目次的な構成ではありません。概念をどのように導入して、どう使っていくか？といった構成ですね。

今後

それらを踏まえると、引き寄せた箇所に直近の見出しも合わせて表示した方がよいかも。SayYes!でやってるみたいに。

また[+]や[-]で、引き寄せて表示する範囲を広げたり狭めたりできますが。このアルゴリズムも改善の余地が…かなり広いですね(^_^;)。いまは、[+]をクリックすると親要素に広がるので、いきなりページ全体に広がったりします。これを、兄弟姉妹の範囲で1つずつ広げるとかしないと。

タグダイレクトの改訂を対訳エディターにも反映しました:

タグダイレクトを改訂しました:

また、長いタグ付きテキストの利用法など、使いこなしの工夫を「タグダイレクトTips」として少しずつ書いていこうと思います。

長いタグ付きテキスト

長いタグ付きテキストを入力しようとするとエラーになることがありました。それを改善した…つもりです。

で、ここからはコーディングの話なのですが…

実験。改行の入らない数百文字のタグ付きテキストを用意して、uxc:Tag_Direct実行してからコピペなどで一気に入力、その後でENTERキーを押さずに、取り消し(undo)してみます。すると、一気に戻らずに何回かに分けて入力した文字列が消えていきます。…う～む、見かけとは異なり、実際の処理では、何回かに分けて入力されているのではないでしょうか？それで、即変換するuxc:Tag_Direct_Right_Nowを使う場合には、全部入力される前の中途半端なタグ付きテキスト(XML)を解釈(パーズ)することになって、文法エラーになっているのでは？

…という仮説をもとに、変換の実行を500ms遅らせてみました。変換して挿入する部分をコマンドとして切り出し、instruction:postインストラクションで実行します。

これで、わたしのPCやMacでは、

• 長いタグ付きテキストでも
• また途中に改行が入っていても、

うまくいくようになりました。その代わり、短いタグ付きテキストでも、変換に一呼吸かかる感じになってしまいました。

いずれ、このあたり、自分の環境や用途に合わせて調整できるようにしようかと:

• ユーザーが、変換実行の遅延時間を調整できるようにする
• ユーザーが、変換キーを変えられるようにする。例えば、ENTERではなくて、Ctrl+ENTERにするとか。

実用に近づく反面、コードがだんだん判りづらくなりますね…(^^;)。そのうち、わたしの限界を超えると思います (^^ゞ。