2007年3月アーカイブ

XMLの仕様書は、文字の規格としてUnicodeを少なからず頼っているので、XML 1.1の仕様書の中にもUnicode用語はしばしば出てきます。Combining CharacterとかComposing CharacterとかPrecomposed FormとかCanonical Decomposition MappingとかPrimary Compositeとか……。最初はCombining Characterを「複合文字」と訳しましたが、その内Composing Characterが出てきて「あれ? 同じ意味じゃ……」と思って数瞬固まりました。The Unicode Consortiumのサイトの情報を色々漁ってみましたが、何だかよく判らず、結局、日本語に訳された形を探してみると……ありましたありました。ものかの - Unicode正規化 その1に欲しい情報がまとめて書いてありました(ありがたい)。ついでにGlossary of Unicode Termsという文書も発見。ほうほう、こりゃ便利。なんで今まで出会わなかったのだろう。

一応、忘れない為に、自分なりに必要な用語をまとめておこう。

Combining Character

文字通りCombining(結合する)Character(文字)。日本語では、主に「結合文字」と訳されるようだ。

日本語の「結合文字」では明らかでないが、Combining Characterという語は、文字通り「能動的に」結合する文字を指す。Combined Characterではない。具体的には、accents, diacritics, Hebrew points, Arabic vowel signs, and Indic matrasなど。The combining character is said to apply to that base character.、らしい。日本語にすると、このapplyは自動詞だから「結合文字はその基底文字に当てはまると言う。」って所か。Combining Characterは、場合によってはBase Characterに先行されない事や、Base Characterに結合する事が(恐らくソフトウェアの制約から)できない事がある。何れの場合でも、Combining CharacterはあたかもそれがBase Characterであるかのように描画される……かも知れない。

辞書には明確に書かれていないが、combineはcomposeよりも「組み合わさる」という点で意味が弱いようだ。むしろ、「くっつく」程度と言った方がいいかも知れない。UnicodeのCombining Characterは文字としてBase Characterと分離されており、例えば──UTF-16ではこのような表現をしても多分問題無いと思うのだけれども、ものかの - Unicode正規化 その1で例に挙げられているポで言えば、Base Character「ホ」#x30DBにCombining Character「゚」#x309Aが当てはまった#x30DB #x309AというCombining Character Sequenceは、一文字ずつ、つまり2バイトずつに分割する事が矛盾無く行える(勿論日本語としては#x309Aが浮くのは駄目だと思うが、これを切り離してどっかに持って行って別の半濁点を付けられるBase Characterの後に置く事が矛盾無く行える、という事)。

参考 : Unicode 4.0.0 - Chapter 3 Conformance - 3.6 Combination - D14 Combining character

Base Character

先行する文字に結合したりしない文字で、制御文字でも形式文字(フォーマット文字?)でもないもの。殆どのUnicode文字はBase Character。日本語では、主に「基底文字」と訳されるようだ。

参考 : Unicode 4.0.0 - Chapter 3 Conformance - 3.6 Combination - D13 Base character

Combining Character Sequence

Composite Character Sequence

Combining character sequenceの定義として、A character sequence consisting of either a base character followed by a sequence of one or more combining characters, or a sequence of one or more combining characters.とある。また、備考としてA combining character sequence is also referred to as a composite character sequence.ってのもある。「一つのBase Characterの後に一つ以上のCombining Characterが続いたもの」から成る一連の文字、あるいは一連の(1文字以上の)Combining Character。文字の並びである事を強調する為にStringを使っていないのかな。Combining Character Sequenceは文字通り「結合文字列」と訳していいだろう。

でも、ものかの - Unicode正規化 その1でも触れられているけど、この意味でComposite Character Sequenceはおかしい気が。少なくとも、誤解を招きかねない、っていうか招くよ、これじゃ……

参考 : Unicode 4.0.0 - Chapter 3 Conformance - 3.6 Combination - D17 Combining character sequence

Composite Character

Precomposed Character

Decomposable Character

A character that is equivalent to a sequence of one or more other characters, according to the decomposition mappings......(後略)、つまりBase CharacterやCombining Characterの組み合わせで表現できる文字を、一つにまとめてしまった文字。日本語にすれば、それぞれ「合成文字」「合成済み文字」「分解可能文字」って所だろうか。

これを見ても、composeはcombineより「組み合わさる」という点で意味が強いようだ。combinationやbondを化学が扱うものとすれば、compositionは錬金術が目指したもの、って感じかなあ(強引かも)。……ああ、核融合がする事って言った方が正確かな。

参考 : Glossary of Unicode Terms - Decomposable Character

Composing Character

これはUnicode用語に見えて実はXML用語で、www.unicode.orgを"Composing Character"でGoogle検索してもヒットしない。将来的には出てくるかも知れないけど。日本語にすると……「合成文字」? うー、Composite Characterと被る。「XMLにおける合成文字」ってしとくか。あるいは開き直って「コンポージングキャラクタ」で通すか。

これはどちらかと言うとCombining Characterの変種らしい。次の何れかあるいは両方に当てはまるものがComposing Characterであるとされている。

1. あるPrimary CompositeのCanonical Decomposition Mappingにおいて2番目の文字。
2. 非ゼロのCanonical Combining Classを持つもの。

意味的には「特殊な結合文字」辺りが的を射ている気がする。

参考 : Extensible Markup Language (XML) 1.1 (Second Edition) - composing character

Canonical

これは形容詞。数学の「極限まで単純化された」辺りの意味からとったものだろう、と思う。Unicodeでは(1) Conforming to the general rules for encoding—that is, not compressed, compacted, or in any other form specified by a higher protocol.という語義が第一に挙げられている。つまり、Composite CharacterをDecompositeした後のCombining Character SequenceはCanonicalと形容されるという事だろうか。日本語にするとしたら、「極限」? 「極単」? それとも、数学のCanonical Formが「標準形」と呼ばれるように「標準」?

参考 : Glossary of Unicode Terms - Canonical

Primary Composite

Glossary of Unicode Termsに拠れば、A character that has a canonical decomposition mapping in the Unicode Character Database (or is a canonical Hangul decomposition) but which is not in the Composition Exclusion Table.との事。UAX #15のD3にも同様の説明がある。Composition Exclusion Tableで除外されているもの以外の、Canonical Decomposition Mappingを持つ文字?

参考 : Glossary of Unicode Terms - Primary Composite、Unicode Standard Annex #15 UNICODE NORMALIZATION FORMS - D3 primary composite

Canonical Decomposition Mapping

Unicode 5.0.0のUNICODE CHARACTER DATABASEを見ると……う、あ、頭が痛くなってきた。うーん、UnicodeData.txtを引っ張ってきて、正規表現^[^;]*;[^;]*;[^;]*;[^;]*;[^;]*;;[^\n]+$で表される行を消した後に残る行が、Decomposition Mappingを持つ文字か。なるほど、LATIN CAPITAL LETTER A WITH GRAVEとか、HIRAGANA LETTER GAとかは分解できる訳か(UnicodeData.txtには5402文字、Decomposition Mappingを持つ文字があるようだ)。でも、NO-BREAK SPACEとかもマップされちゃうんだなあ。

Character Decomposition Mappingでは、The tags supplied with certain decomposition mappings generally indicate formatting information. Where no such tag is given, the mapping is canonical.とも書いてある。続けて、Conversely, the presence of a formatting tag also indicates that the mapping is a compatibility mapping and not a canonical mapping.ともある。そのthe compatibility formatting tagsは、テーブルでそれらのタグ(例えば<font>、<noBreak>、<initial>など)がリストにまとめられている。ふーん、じゃあ、更に^[^;]*;[^;]*;[^;]*;[^;]*;[^;]*;<[^;]+;[^\n]+$で表される行を弾いた後の、こういうタグがついていないLATIN CAPITAL LETTER A WITH GRAVEとかLATIN SMALL LETTER A WITH GRAVE、HIRAGANA LETTER GAとかの2043文字はCanonicalがついた方のCanonical Decomposition Mappingを持つ訳ね。

Primary Compositeは、正確にはA character that has a canonical decomposition mapping in the Unicode Character Database (or is a canonical Hangul decomposition) but which is not in the Composition Exclusion Table.だった。だから、UnicodeData.txtの文字について言えば、これらの2043文字の内、CompositionExclusions.txtに載っている1009文字の内、UnicodeData.txtにも載っているものを除いた文字がPrimary Compositeという訳だ。え? Unihan.txt? ……28MBもあるし、インクリメンタルレンダリングが苦手というレベルではないIE7が見事にお逝きになったから、抵抗が……FirefoxとかOperaなら大丈夫かしら。てか、きっとIE7はレンダリングを別のスレッドでやってないか、スレッドの優先順位がおかしいんだね。おっと脇道に逸れた。

XML 1.1の仕様書では、Primary CompositeのCanonical Decomposition Mappingの二文字目が、Composing Characterになる一つの条件だった。何でこんな書き方をしているのかと思って調べてみると、UnicodeData.txtに載っていたCanonical Decomposition Mappingを持つ文字(注意、Primary Compositeではない)2043文字の内、二文字のマッピングを持っているものが1013文字で、一文字のマッピングを持っているものが残りの1030文字、つまりUnicodeData.txtには三文字以上にマップされる文字は無かった。これが、the second character in the canonical decomposition mapping of some primary composite (as defined in D3 of UAX #15 [Unicode])とい表現を生んだのだろう。なんで"the second character or later...."ってならないのかと思ってたら、こういう訳ね。……え? Unihan.txt? ……。

参考 : UNICODE CHARACTER DATABASE - Character Decomposition Mapping

Decomposition

Full Decomposition

大体の場合、分解。(1) The process of separating or analyzing a text element into component units. These component units may not have any functional status, but may be simply formal units—that is, abstract shapes.。Composite CharacterをCombining Character Sequenceにする処理の事だろう。Canonicalな場合はCanonical Decompositionを参照。Compatibilityな場合は省略。(2) A sequence of one or more characters that is equivalent to a decomposable character.ってのもあるから油断できない。こちらは分解した後のもの、って事で「分解後の文字列」?

(1)の意味の分解では、文字によっては元から一文字で、分解できるはずが無いのに、(文字の数が増えるのではなく)別の文字に変わってしまうものもあるらしい。

参考 : Glossary of Unicode Terms - Decomposition、ものかの - Unicode正規化 その3

Canonical Decomposition

次のように遂行される、あるいは次のように遂行されたのと同じ効果を持つDecomposition。

1. Canonical Mappingを再帰的に適用して、完全にCanonicalなCharacter Sequenceを作る。
2. Canonical Reordering Algorithmを適用する。

Canonical Decomposition MappingはCompositionの時にも使われるから、ここではCanonical Mappingとなっているのだろう。Canonical Reordering Algorithmは、多分UAX #15のD2辺りで説明されている話で、Starter(Combining Classに0を持つ文字)SとCombining CharacterであるCがBにblockされないようにする処理の事だろう。つまり、BがCombining Characterであれば、Combining Classが低い順にSの後ろに並べる(その場合SCB)という事だと思われる。UCDのDecompositions and Normalizationで触れられているように、現在ではこのReorderingは実質的には必要でないらしい。が、必ずしなければならない(MUST)らしい。将来のバージョンで必要になる可能性があるのかしら。

reorderはre+orderだし、3.11 Canonical Ordering Behaviorをもう一回しろって所かも。

参考 : UNICODE CHARACTER DATABASE - Character Decomposition Mapping、Unicode 4.0.0 - Chapter 3 Conformance - 3.11 Canonical Ordering Behavior

Combining Class

A numeric value given to each combining Unicode character that determines with which other combining characters it typographically interacts.らしい。

参考 : Glossary of Unicode Terms - Combining Class

Canonical Combining Class

UCDのUCD Proprty FilesのUnicodeData.txtの説明で、Canonical_Combining_Classフィールドの説明には(3) The classes used for the Canonical Ordering Algorithm in the Unicode Standard. For the property value names associated with different numeric values, see DerivedCombiningClass.txt and Canonical Combining Class Values.とある。

このフィールドはデフォルト値として0を持っているようだけど、省略しているものは無いようなので^[^;]*;[^;]*;[^;]*;0;[^\n]+$の行を消すと、UnicodeData.txtには418の非ゼロCombining Character Classを持つ文字がある事が判る。Property Invariantsにも書いてあるけど、現段階ではGeneral CategoryがMn(Mark, Nonspacing)以外の文字は全てこの値に0を持つようだ。将来的にも、Mc(Mark, Spacing Combining)とMe(Mark, Enclosing)に分類される文字が0以外の値を持つ可能性はあるけど、それ以外のカテゴリの文字なら必ず0を持つ事がinvariant(不変)とされてる。

参考 : UNICODE CHARACTER DATABASE - Canonical Combining Class Values

Canonical Equivalent

名詞句。Two character sequences are said to be canonical equivalents if their full canonical decompositions are identical.だと。「極限一致文字列」? なんか気持ち悪いな。「究極一致文字列」? 「完全一致文字列」?

形容詞句Canonically Equivalentってのもあるけど、こっちは定義無しに使われている気がする。

参考 : Unicode 4.0.0 - Chapter 3 Conformance - 3.7 Decomposition - D24 Canonical Equivalent

Primary Combined

A character X can be primary combined with a character Y if and only if there is a primary composite Z that is canonically equivalent to the sequence <X, Y>.というように使われる。Primarily Combinedじゃないのね。

参考 : Unicode Standard Annex #15 UNICODE NORMALIZATION FORMS - D4 primary combined

Normalization Form C

「正規形C」らしいけど、これは固有名詞でいいような気もするなあ。具体的には、文字列SのNormalization Form Cは次の手順を踏むことで得られる(同じ結果が得られればこの通りでなくても良い)。

1. Unicode Character Databaseの最新版に収められているDecomposition Mappingを用いて、文字列SのCanonical Decompositionを生成する。このDecompositionは(2)の意味っぽいな。
2. 分解後の文字列に含まれる文字Cそれぞれについて、次の処理を繰り返す。もしCが直前のStarterからblockされておらず、なおかつCがLとPrimary Combineできるのであれば、LをPrimary CompositeであるL-Cで置き換えて、Cを削除する。

ははぁ、なるほど。やる事は(Primary Compositeの判定を除けば)実に単純明快だけど、ここまで辿り着くのは中々大変だなあ。

参考 : Unicode Standard Annex #15 UNICODE NORMALIZATION FORMS - R1. Normalization Form C、ものかの - Unicode正規化 その4

Kanji

勿論「漢字」の事。ちょっと不思議に思って調べてみたら、The Japanese name for Han characters; derived from the Chinese word hànzì. Also romanized as kanzi.だって。ははぁ、なるほど、それでUnicodeData.txtには漢字が入ってない訳。……って事はやっぱり、Unihan.txtの中なんだろうなあ。

参考 : Glossary of Unicode Terms - Kanji

でも、Unicodeの資料って、自分でXMLの仕様書に書いてある事を理解しようと思って色々調べてみても、結局翻訳する時には殆ど現れない事が多いんですよね。だからUnicodeなんて大嫌いだ。でもUnicodeが大好きです。

はあ、XML 1.1 Second Editionの翻訳はそろそろ3 Logical Structureに入ろうかという所。2.13 Normalization CheckingとかいうUnicode用語を臆面も無く使うセクションがあるからだ。

「整形式」とは何か

XMLの仕様書には、"well-formed"とか"well-formedness"という単語が出てきます。英語では一般的な単語で、形容詞"well-formed"の原義は文字通り「形の良い」といった所で、言語学では転じて「適格な」「(理論・体系に)合致した」となり、名詞"well-formedness"は「well-formedである事」らしいのです(手許の電子辞書のジーニアス英和大辞典に拠ると)。XMLを扱う日本語の文書では、"well-formedness"の訳語は「整形式」(「整」+「形式」)と相場が決まっているようです。よって今書いている翻訳版でもこの訳語を使う事にしています。一方、"well-formed"の訳語は「整形式の」が主流なようです。これは、「整形式」という語の組成から──「形式」は名詞であり、そこに形容詞的働きをする(名詞を修飾する)「整」が付いているから──「整形式」は名詞句(あるいは、固有名詞? ちなみに、ここでは「句」をphraseの意味で使います)であり、ここから形容詞を作る為格助詞「の」を使って「整形式の」となったのでしょう。「の」から転じたらしい「な」にも格助詞として似たような意味はあるようですが、「形式」に付くと変な感じがします(恐らく、殆どの人が「新しい形式な文書」や「古い形式な書類」という表現を不自然と感じるでしょう)。

さて、言語学なんてかじった事もありませんが、この記事では(多分)中学校で習った日本語の文法知識と日本人としての経験を基に、僭越ながらこの「整形式」について、というより「整形式」がきっかけとなって考えた事を書き下してみようと思います。

"well-formed"と「整形式の」

形容詞句「整形式の」は、"well-formed"が限定用法で使われている間は役に立ちます。"a well-formed document"は「整形式の文書」でいいでしょうし、"a well-formed parsed entity"は「整形式の解析対象実体」(ここではparsed entityの訳語がこれでいいかどうかについては問題にしません)でいいでしょう。が、well-formedが叙述用法で使われた場合は困ります。"The document is well-formed."は「その文書は整形式の。」……じゃおかしいですよね(当たり前か)。この場合「その文書は整形式である。」が妥当でしょうか。もう少し柔らかくすれば「その文書は整形式だ。」でしょう。今書いている仕様書では使われる予定はありませんが、「です」を使えば「その文書は整形式です。」となります。勿論、これを逆翻訳した時"The document is well-formedness."となる事は期待しません。やはり"The document is well-formed."となる事を期待します(本筋から逸れますが、敢えてwell-formednessを使うなら、"The document has well-formedness."ですかね)。つまり、「整形式である」「整形式だ」は形容詞的な働きをする事を意図しています。

日本語の「である」「だ」「です」

「である」や「だ」、「です」を広辞苑第五版で引いて、関連する言葉と併せて要約してみます。

である

「にて」のつづまった「で」と動詞「ある」が接合したもの。この「にて」の品詞は書かれていませんが、元の「だ」や「である」が断定の意味を持つ事から、助詞「にて」ではなく連語「にて」なのでしょう(連語は品詞の一種じゃないから品詞書いてないんでしょうか)。連語「にて」を見てみるとまた語義が二つありますが、片方は「完了の助動詞『ぬ』の連用形『に』に接続助詞『て』の付いたもの」でもう片方は「断定の助動詞『なり』の連用形『に』に接続助詞『て』の付いたもの」なので、もとめる「にて」は後者でしょう。

活用は動詞「ある」のもの、つまりラ行五段活用、とすると、語幹も含めて書けば「であら・であろ/であり・であっ/である/である/であれ/であれ」となりますが、未然形の「であら」に否定の助動詞「ず」を使うと"The document is not well-formed."に対して「その文書は整形式であらず。」となって変ですね。補助形容詞(なんてのがあるんですね)「ない」を使って「ではない」とすれば自然ですが、これって本当に「である」の活用?

だ

「にてある」から「である」、「であ」、「だ」と転じた助動詞。断定を表す、とあります。

活用は「だろ/だっ・で・に/だ/な/なら/○」。

です

体言や体言に準ずる語句、一部の助詞について、指定の意を表す助動詞。特に、普通に使われる「です」は、「丁寧の意味を込め、指定の意味を表す」ですでしょう。

活用は「でしょ/でし/です/です/○/○」。

つまり、「である」も「だ」も「です」も、直前の語に接続するものは助動詞という訳ですね。

具象名詞と抽象名詞

英語などの助動詞から連想すると、助動詞が付くのは用言だけかと想像されますが、日本語の助動詞は必ずしも用言に付く訳ではないようです(英語などのヨーロッパ言語の助動詞は必ず動詞に付きますよね。「動詞」に意味を付け加えて「助」けるから「助動詞」と言う訳で)。先程取り上げた三つの助動詞は体言や助詞にも付き、実際、「私が太郎の父である。」「これは不良品だ。」「彼らはごろつきです。」という文は名詞に接続していますが、自然に受け容れられます。これらの文は「(代)名詞=名詞」あるいは「(代)名詞の作る集合⊂名詞の作る集合」(場合によっては「(代)名詞∈名詞の作る集合」もあるかも知れない)という構図になっていて、英語に訳せば"I am Taro's father." "This is a defective product." "They are vagabonds."となり、主語も名詞、補語も名詞です。

別の例文を考えてみます。「真理を追究するのに信念は無用である。」「そんな事をするのは無理だ。」「窓から身を乗り出す事は危険です。」を訳すとすれば、それぞれ"Belief is useless to quest for truth." "It is impossible to do such a thing." "Leaning out of the window is dangerous."のようになるでしょう。主語は名詞ですが、補語は形容詞になっています。まあ、必ずしも形容詞にする必要は無いでしょう。例えば最後の例文の訳を"Leaning out of the window is a danger."としても、間違いとは言えません。dangerには「危険なもの、人、事」という可算名詞もあるからです。ですが、それを再び日本語に直訳すると、「窓から身を乗り出す事は危険な事です。」となるでしょう。とすると、これら「無用である」「無理だ」「危険です」は形容詞的なもので、性質の概念を言い換えたいのではなく性質の形容をしたいのだと言えます。もしこれらを概念の言い換えだと解釈すると、その訳語は"usefulness" "impossibility" "danger"(このdangerは不可算名詞のdangerであり、可算名詞ではない)になります。これをそのまま置き換えると"Belief is uselessness to quest for truth." "It is impossibility to do such a thing." "Leaning out of the window is danger."となり、おかしな訳文になってしまいます。beliefはusefulnessの部分集合ではありませんし、to do such a thingでimpossibilityを、leaning out of the windowでdangerを言い換えられる訳でもありません。

さて、このセクションで最初に挙げた例文三つは、主語も名詞、補語も名詞になりました。次に挙げた例文三つは、主語は名詞でしたが、補語は形容詞になりました。ではこのセクションの始まりよりも前に挙げた例文、「その文書は整形式である。」はどちらの型に当てはまるでしょうか。勿論後者ですね。well-formedは形容詞であり、well-formednessは「well-formedである事」という性質の概念ですから、"The document is well-formedness."とするとthe documentが概念well-formednessの部分集合あるいは言い換えのように聞こえます。「整形式である」とか「整形式だ」というのは、性質を形容したくて使うのですから、それには形容詞well-formedを使う訳です。「整形式」を単独で使えば、性質の概念と言えそうです。

性質の概念の修飾

さて、ここまでの性質の形容は叙述的でした。では、性質の形容を限定的に表す場合、つまり体言を修飾する場合はどうなるでしょう。適当な言葉を考えてみると、「無用な心配」「無理な要求」「危険な賭け」は自然な日本語として受け容れられそうです。それもそのはず、「体言の後に付けて、その状態にある事を示す」事もある助動詞「だ」は、「だろ/だっ・で・に/だ/な/なら/○」と活用する為、その連体形「な」を使って、「無用」+「な」+「心配」、「無理」+「な」+「要求」、「危険」+「な」+「賭け」とする事ができる訳です。「です」の連体形を使うと変な感じがします(広辞苑第五版には「です」の連体形が載っていますが、明鏡国語辞典には「です」の連体形が載っていないのはこの為でしょう)が、「である」の連体形「である」を使っても、そんなに不自然には感じません。と言う事は、性質の概念であろう「整形式」も、「だ」や「である」を活用させて限定的な修飾ができるはずです。とすると、"a well-formed document"の訳語として「整形式な文書」は自然な日本語として受け容れられ……、ますか? 少し変な感じがします。この事は冒頭でも触れました。「形式」に助詞「な」がつくとおかしい、例えば「新しい形式な文書」や「古い形式な書類」はおかしな感じがします。でも、先程述べたように、今回の「整形式な文書」に含まれる「な」は、助詞ではなく助動詞「だ」の活用形のはずです。「整形式」は性質の概念のはずですから、「無用」「無理」「危険」のように、「だ」の連用形「な」を付けて繋いでもおかしくないのが普通でしょう。何故矛盾するのでしょう?

「整形式だ」と「整形式の」の間の壁を解消する解釈

実は、この矛盾は当たり前の事です。何故って、語の組成の時は「整」に「形式」を修飾させ、"a good form"というような作り方をしたのに、その意味は「整った形式である事」、つまり"well-formedness"にしてしまったからです。語の組成に使われた「形式」という日本語は「外面に現れる形」、つまり英語の"form"の主な語義とほぼそのまま対応します。「形」は勿論性質ではありません。しかし、「この文書は新しい形式だ。」と言う事もあります。これは、「この文書は新しい形をしている。」「この文書は新しい形式を持っている。」というように解釈される事を意図した、言わば省略された文です。「文書」が「新しい形式」そのものではないでしょう。また、「新しい形式の文書を解析できるプログラムはまだ無い。」という文も自然に聞こえます。これも「新しい形をしている文書を解析できるプログラムはまだ無い。」などのように解釈される事を期待しているのでしょう。でも、助詞「な」を使って「新しい形式な文書を解析できるプログラムはまだ無い。」とした文書は奇妙です。文法的には助詞「な」は助詞「の」の転なので問題無いのでしょうが、普通は使いませんよね。助動詞「だ」の連体形「な」を使ったと考えても、「新しい形式な文書を解析できるプログラムはまだ無い。」は変です。「形式」は性質ではないので、「この文書は新しい形式だ。」という文は「この文書」が「新しい形式」という状態ならぬ状態にある事を示すのではなく、「この文書」が「新しい形式」という「もの」そのものを示すのでもなく、「この文書は新しい形式を持つものだ。」という文の省略形である事を示すからです。名詞「形式」と助動詞「だ」は繋がっているように見えて、実は繋がっていないのです。だから、あたかも直接繋がっているかのように助動詞「だ」を活用すると変なのでしょう。

「整形式」の場合も「形式」と同じように、「その文書は整形式である。」と言った場合、「その文書は整った形をしている。」「その文書は整った形式を持っている。」と解釈されるべきもの、つまり「その文書は整形式を持つものだ。」という文の省略形である事を示唆するでしょう。そして、「整形式の文書」と言う時は、「整った形をした文書」「整った形式を持つ文書」と読まれる事を期待します。……あれ、では何にも問題は無い?

「整形式」と"well-formedness"

いや、いや、一つあります。「整形式」を「形式」の一つとしてしまえば、その訳語は明らかに"a good form"になります。「整った形式を持つという性質」でなければ"well-formedness"にはなりません。英語で"well-formedness constraint"と表される句を「整形式制約」と訳すのは飛びすぎではありませんか?

現存するXML関連の文書との協和を重視するなら、「整形式」という言葉は残すべきなのでしょう。"The document is well-formed."の訳文に「その文書は整形式である。」を使い、"a well-formed document"の訳語に「整形式の文書」を使い。ただ、"well-formedness"に対しては、性質を表す名詞「整形式性」を使うべきだと思います。

でも、ほんとは

本当の所を言うと、"well-formed"や"well-formedness"の訳語に、名詞「整形式」は使わない方がいいと思っています。「その文書は整形式である。」や「その文書は整形式だ。」という文は誤解されやすく、何より「整形式」という言葉が性質でない以上、普通に連体形に活用させて修飾する事が不自然になり、「整形式の」という例外を生んでしまいます。性質を表していてかつ誤解される恐れの少ない言葉を新しく考えるのは難しいとは思いますが、例えば……

形容動詞「整形式だ」

助動詞「だ」から、「体言の後に付けて、その状態にある事を示す」語義を奪い、形容動詞という品詞を確立させて「整形式だ」を造るという案。名詞「整形式」は廃し、性質を表す名詞「整形式性」を導入します。形容動詞「整形式だ」の語義は「形が整っている。形が良い。」事とか、XMLの仕様書を示して「この仕様書に書かれている全ての整形式性制約を満たす。」事とし、名詞「整形式性」の語義は「整形式である事。整形式さ。」とします。"The document is well-formed."の訳文として「その文書は整形式だ。」を、"a well-formed document"の訳語として「整形式な文書」を、"well-formedness constraint"の訳語として「整形式性制約」を使います。

ついでに、性質を表す名詞「無用」「無理」「危険」や、その他「簡単」「困難」「静か」「穏やか」「綺麗」「勤勉」「怠惰」などはそれぞれ形容動詞として、性質を表す以外の意味が無い名詞(「簡単」とか、「静か」とか。「無理」や「危険」などは、「無理な事」「危険な事」などという意味もあるのでなくすとまずい)については元の名詞を撤廃してしまえばいいと思うんですけどねえ。(日本語についての)言語学を知らないので、形容動詞を品詞として確立する事の弊害も知らないんですが、どうなんでしょう。というか、日本語の助動詞って本当に助動詞? (参考:助動詞のない文法)

形容動詞「整式だ」

いっその事、「形式」とか「整形」とか、辞書に別の項目で載ってしまうような単語を入れるのではなく、普通人が見たら辞書をその言葉全体で(この場合「せいしき」で)引こうとするような単語にする案。「整形式」を「整式」に変える他は、形容動詞「整形式だ」と同じ(つまり、名詞「整式性」も造ったりする)。

代数学の専門用語に既に名詞「整式」がありますが、これも専門用語だから誤解される恐れは少ないでしょう。

形容動詞「式整だ」

造語なのだし、既存の単語に拘らず、漢字の意味と、意味の流れを重視して造った案。「整形式」を「式整」に変える他は、形容動詞「整形式だ」と同じ。

はしがき

この記事は考えながら書いたので、ちょっと冗長かも知れません。もう少し考えがまとまったら、書き直すかも。

現在、2.4 Character Data and Markupの頭。この記事を書いていたら大分時間を食ってしまいました。にしても、XMLの仕様書って流し読みとか拾い読みには向いてないなあ。と、通し読みしながら思った。

よく見てみたら、XML 1.1 Second EditionはXML 1.0 Fourth Editionをsupersedeしないのですね(勿論XML 1.1 First EditionもXML 1.0 Third Editionをsupersedeしない)。というか、XML Core Working Group Public PageのPublicationsでもYou are encouraged to create or generate XML 1.0 documents if you do not need the new features in XML 1.1; XML Parsers are expected to understand both XML 1.0 and XML 1.1.とか書いてあります。……まぁ、いいや。XML 1.1での変更点をおさえておけばXML 1.0の理解にも役立つだろうし、XML 1.0には(第一版ですが)XML Working Groupメンバの一人でもある村田 真さんが主査のXML 1.0の翻訳版もある事だし。

Extensible Markup Language (XML) 1.1 (Second Edition)の翻訳を始めました。XMLの仕様書を通し読みしてみようと思い立ち、どうせだから最新版を読んでみようと考え、折角だから翻訳してしまえ、と。半分以上は自分の為なのです。人にものを教える時、もっとも教えられているのは教えている本人である……とか何とか言いますものね。

多分、未完成版を公開した後ちょこちょこ翻訳を追加していくよりは、改訂を残すのみとなった完全版を公開する方が(W3Cにとって)楽だと思うので、完成するまでは公開しません。進捗状況はこのウェブログでちょこちょこ書くつもりです。

今日も朝から翻訳中。今は2 Documentsの頭。

HTML 標準の更新に着手というW3Cのプレスリリースについて取り上げた新しいHTML標準?という記事を書きましたが、やはり少し性急に過ぎたようです。どうもこのプレスリリースから感じ取れる「今後は今までのXHTMLを使うのではなく新しいHTMLを使うべし」という意味ではなかった模様。

神崎さんのメモ(HTMLの再構築？、W3Cの新HTML作業部会)によれば、この計画はWWWの発案者(URI、HTTPやHTMLなどの発案者)であるTim Berners-Leeさんも早くから触れていたそうで(原文:Reinventing HTML)、目的はむしろ「XHTMLやXMLへの移行を逆行させるものではなく、過渡的な段階を増やす事」らしい。という事で、プレスリリースにもXML に準拠したコンテンツ市場は今後も成長の一途をたどり、重要度も増すと考えられるため、W3C では、新たに策定される HTML に対しても、旧来からの HTML 構文だけでなく、XML 形式での構文も定義することにしていますと書いてあります。……いや、でもこれ「XHTML 2.0は分流で新HTMLが本流」って言っているように見えませんか。でも、「過渡的な段階はXHTML 1.0やXHTML 1.1だけでは足りない」というのが本当の所らしいようで。

今回The Web KANZAKIのちょっとしたメモを見つけて発見したのですが、分流と言えばWHATWGという団体もあるそうですね。HTML 5などの仕様を策定しようとしていた団体……らしい。尤も、W3Cも新WGへの参加を呼びかけているそうですし、WHATWGもサイトでWe intend to work more closely with the W3C in future.と言っているので、これは合流するようです。

しかしWHATWGのWeb Applications 1.0の仕様書、一つの文書で341KBって……インクリメンタルレンダリングの苦手なIE7が長い事ハングアップするんですけど、分けないんですかね。また得意のフリーズかと思って、Headline-Reader Liteをkillしちゃいましたよ。XSLの仕様書(一つの文書で1735KB、あえてリンクせず)といい勝負ですね。

IEって、widthの計算に弱いですね……IE6もIE7も。

IE6より前のIEの為にapplication/xhtml+xmlからtext/htmlに戻してみたりとか、身に覚えの無いActive Xコントロールを実行する為の確認をIE6で求められた為にobjectをimgに戻してみたりとか、IE6でも見苦しくないtableのwidthの指定方法を模索してみたりとか……大した事やってないのにどっと疲れました。IE7でもよく見るとテーブルの横幅がおかしい(右のマージンが多い)。widthの計算なら、昔のようにdiv#bodyでpaddingを指定するんじゃなくてh2～h4、div.section、ul、ol、tableなどについてそれぞれmarginでやれば崩れなかった気もしますが、……何だかそこまで戻すと……いや、戻すべきなのかも知れませんね。

とあるサイトのアクセスログ解析を紹介している日記があったので見てみたら、そこのサイトではIE6が77%だという事です。その割合がリクエスト数のものなのかユニークホスト数のものなのか書いてなかったので何とも言えないのですが、まぁでもIE6のシェアはまだまだ高いんでしょうね。

これかー? 迷い蜂に刺されたか噛まれたと思ってたけど、何気なくWikipediaのアシナガバチの項目を見ていたら、こんなものが。

性質はスズメバチに比べればおとなしく、巣を強く刺激しなければまず刺してはこない。刺傷は子供などが巣を刺激して起こるケースと、洗濯物等に紛れ込んでいるアシナガバチに気づかず起こるケースとがある。毒はスズメバチに比べれば弱いが、アナフィラキシーショックにより死亡することもあるので過去に刺されたことがある人は注意が必要。

アナフィラキシーショックとかいうものは起こりませんでしたがね。

記事のタイトル、元の歌詞はうろ覚え。

前後しますが、HTML 標準の更新に着手というプレスリリースがW3Cから出されています。XHTMLの導入が遅々として進まず、HTML 4(と言うよりはHTML 4.01だと思うのですが)が事実上の標準の座から降りない為に、HTML 4を基準とした、後方互換性にも配慮する新しいHTMLを作ろうという事らしいです。XHTML 2.0については、既に取組みを進めている活動については継続する一方で、市場における価値や独立性を明確化すべく、名称変更も含めた検討を行いますとの事。HTML Working Group Charterによれば、勧告は2010年を目標にするようですね。

個人的には、面白くありません。Web の開発や設計に携わる関係者らが要求する実際の利用実態に即したHTMLっていうのはつまり、b要素やi要素やfont要素なんかがあるHTMLっていう事なんでしょう。これらの殆ど全てはXHTML 2.0では駆逐されるでしょうし、font要素など一部の要素はXHTML 1.1で既に放逐されてますものね。

違う、違う、HTMLの進むべき道はHTML 4の延長ではないはずです。CSSを知る人は、HTML 4のプレゼンテーション用要素の非効率さに気付いているはずです。XSLTを使う人は、厳密なツリー構造を持つデータがどれ程扱いやすいか解っているはずです。Microsoft Wordを愛用する人は、文書の構成要素に対して、別に定義した「スタイル」を適用する事の威力を肌で感じているはずです。構造とスタイルを分離する事は、遠回りなように見えて、却って近道です。

我々が、例えば本から情報を得る時、(目に障害が無ければ)文書構造は見た目から得ます。綴じられた本の一番最初に大きな文字で「ドルリイ・レーン 最後の事件」と書いてあれば、それが本のタイトルだと認識します。前後に数行の空白があり、少し字下げして「3 十九番目の男」と書いてあれば、それが見出しだと思います。改行されて一文字字下げされれば、新しい段落に入った事が判ります。太い活字で文章が書いてあれば、重要な事なのだと判断するでしょう。でも、見た目と文書構造は必ずしも一致はしません。要点は、必ずしも太字でしょうか? 赤い文字は重要じゃないのですか? 段落の区切りは必ずしも改行、一字下げですか? 時々見かける、「* * *」という罫線みたいなものは何ですか? 見出しは必ずしも数行の空白を伴いますか? 文字が大きく太くなって、数行の空白を伴わない文字列は段落なのですか? また、英語の文書では、字下げの代わりに一行の空白を空けて文章が並んでいる事がありますが、あれは段落ではないのですか? ──スタイルに配慮する事が無意味だとは言いません。むしろ、良いスタイルを与えられた文書は、文章が読みやすくなります。明確な基準で意味や文書構造と見た目が対応する文書は、構造を捉えるのが容易になります。でも、それはHTMLでやる仕事じゃないでしょ。CSSやXSL-FOとかでやる仕事でしょ。構造の記述とスタイルの記述を分離すると、HTMLソースは恐ろしい程見やすく、自分でも構成を理解するのが格段に容易になります(これは元々のソースの複雑さにも依りますが)。タイトルはtitle、見出しはh1からh6まで、段落はp、HTMLを書くのに最低限必要なのはこれだけでしょう? 実際、

<!DOCTYPE HTML PUBLIC
  "-//W3C//DTD HTML 4.01 //EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<title>タイトル</title>
<h1>見出し</h1>
<p>段落</p>

は妥当(Valid)なHTML 4.01 Strictです。勿論、p要素だけでは色々な形式のデータを表現できませんから、ulとかolとかdlとか、emとかstrongとか、qとかblockquoteとか、他の要素を使って意味や構造を表す訳です。大体のブラウザはMosaicスタイル? を採用してemで囲まれた文字列は斜体で表示しますが、私は強調は斜体じゃなくて太字でやりたいんだ、って人は、CSSを使ってem { font-weight : bold; font-style : normal; }とかやる訳です。……人によって、「強調」という意味に与えるスタイルは異なるのですから。

僕の拙い主張じゃ納得できんって人は、RagettさんのGetting started with HTMLとか、神崎さんのごく簡単なHTMLの説明とか、すみさんの「via Internet」談義とかを読むといいのです。僕が初めてこういう思想に触れたのはごく簡単なHTMLの説明でだったのですが、初めて見た時は鳥肌が立ちましたよ。「正しいHTMLは美しいものなんだ」って。

どうも僕には、今回の新しいHTMLはHTML 3.2の再来のような気がしてなりません。仕様が現状に迎合していたのでは、いつまで経っても先に進めないと思うのですが……。

あーやだやだ、なんでどれもこれも横幅もフォントサイズもピクセル固定のスタイルばかりなんでしょうかMovable TypeのStyle Catcherで取得できるスタイルは。Styleとしては合格かも知れませんが、Designとしては不合格じゃないでしょうか。適当にいじって横幅もフォントサイズも可変にしてみましたが、こんなんじゃ気軽にスタイル変えられないですね。はぁ、これでまた一つ消滅事由が増えた。

愚痴はさておき、FLAC(Free Lossless Audio Codec)のバージョンが1.1.4になっていたので、今まで使っていたFLAC用のDLLもバージョンアップしました。以前のDLLはlibflac-1.1.2を使っていたので、結構違いがありました。と言っても1.1.4はプログラミングインターフェースには大した差は無くて、大きな変更があったのは1.1.3なんですが、

• file_decoder、seekable_stream_decoderはstream_decoderに統合
• libOggFLAC、libOggFLAC++はそれぞれlibFLAC、libFLAC++に統合
• stream_decoderの初期化方法の変更(但し、その他の面では統一的に扱えるようになった)
• 他、ステータスを表す列挙型のメンバの変更

……などなど、まぁ変えなければならない箇所がわんさか。おまけにlibflacは、libvorbisのものよりもソースに手を加えなければならない箇所が多い(28箇所、コールバック関数の呼び出し規約を__stdcallに変えなければならない)ので、ちょっとうんざりしました。nasmからエクスポートされる関数が__cdeclなもんで、既定値を__stdcallにすると余計面倒くさくなりそう(未確認)なんですよねぇ。まぁ、スマートになったから良しとしますか。

ちなみにFLAC 1.1.4の最大の魅力はエンコード速度・デコード速度の劇的な上昇で、-8オプション(最高圧縮)のエンコードスピードは約2倍になったとか(体感的にもそのくらいです)。デコードの方は調べていませんが、最近作っていた曲のループ境界探索ツールで実験した所、同じサウンドデータから作ったRIFF Wave(生のPCM)オーディオ、Ogg Vorbisオーディオ、Native FLACオーディオ、Ogg FLACオーディオに対して同じ条件で探索してみても、かかる時間は全て約5分で、有意な差は殆ど感じられませんでした。

ここ一週間、libflac-1.1.4の他にも、DirectSound周りのライブラリやそのテスト用ツールを改良していました。大分満足できるできになりましたが、Direct3D周りにはまだまだやる事が残っているのでした。

OggVorbis_Fileって、ヒープ中で完全に位置が固定されている事を仮定しているんでしょうか? 今作っている曲のループ境界探索ツール(?)でAccessViolation問題が再発したので、試しに次のようにしてみたら、ぴたりと止みました(また気のせいかも知れませんが)。

public class OggVorbisFile : IDisposable {
  #region コンストラクタ/ファイナライザ
  public OggVorbisFile() {
    this.data = new byte[ 720 ];
    this.gchandle = GCHandle.Alloc( this.data,
      GCHandleType.Pinned );
    this.address = Marshal.UnsafeAddrOfPinnedArrayElement
      ( this.data, 0 );
    return;
  }
  ~OggVorbisFile() {
    this.Dispose();
 
    return;
  }
  private bool disposed = false;
  public void Dispose() {
    if ( this.disposed )
      return;
 
    this.gchandle.Free();
 
    this.disposed = true;
    GC.SuppressFinalize( this );
 
    return;
  }
  #endregion
  #region 実体
  byte[] data;
  GCHandle gchandle;
  IntPtr address;
  #endregion
  #region 型変換
  public static implicit operator IntPtr
    ( OggVorbisFile oggVorbisFile ) {
    return oggVorbisFile.address;
  }
  #endregion
}

OggVorbis_Fileは720バイトだという事を既知として(無論、libvorbisのバージョンアップによって変わる可能性はあります)、720バイトのbyte配列を作り、GCHandleでpinする、つまりヒープ中でのアドレスを固定するというものです。以前のOggVorbisFileと違う所は、ヒープ中で固定されているかいないかだけ(のはず)なのですが、何故なんででしょうねぇ(libvorbisのソースを見ていないので、これで解決できているのかどうかは断言できませんが、OggVorbis_Fileのメンバにアクセスしないのであればこれが一番簡単なCヒープの模倣手段でしょう)。

ついでに、セカンダリバッファを更新するスレッド「だけ」で、ファイルのov_open_callbacksからov_readまでの処理をするようにしていましたが、ov_open_callbacksをメインスレッドで、ov_readを別スレッドで呼び出すようにしても、AccessViolationが出なくなりました。これでdeferOpeningとかいう、あまり外部に見せたくない引数を消す事ができました。

2007-03-09追記: この方法を使う時は、アンマネージド関数のプロトタイプ宣言で[In, Out] OggVorbisFile oggVorbisFileとしていた所は、IntPtr oggVorbisFileに変えておいてください。暗黙の型変換が行われるので、労力は小さくて済むでしょう。