概要: Extensible Markup Language (XML) 1.0 (Fifth Edition)を翻訳して、Extensible Markup Language (第五版)で公開しました。今回...
Extensible Markup Language (XML) 1.0 (Fifth Edition)を翻訳して、Extensible Markup Language (第五版)で公開しました。今回はFourth EditionのErrataを見て修正箇所を探す事ができたので楽でした。尤も、たまにErrataに載っていない細かい修正があったりして気は抜けませんでしたが。
......何か色々書こうと思ったのですが、ぐだぐだになりそうだったので没にしました。ただ、Fifth Editionをサポートする実装が増えるといいですね。今回はXML 1.1の時と違ってIntelやMicrosoftが既にテストスイートをパスする実装を作ったようなので、時間が経てばXML 1.1の夢も果たされるかも知れません。
......Intel、Microsoftと言った所で思い出しましたが、IBMのメインフレームで使われているらしいNEL(#x85)は改行文字に追加されてないですね。Unicodeの#x2028も。何故だろう......
概要: はっ、いつの間にかExtensible Markup Language (XML) 1.0 (Fifth Edition)が勧告されてる......そうか、Outlookが登録されたRSSを確認無しで...
はっ、いつの間にかExtensible Markup Language (XML) 1.0 (Fifth Edition)が勧告されてる......そうか、Outlookが登録されたRSSを確認無しで綺麗に消してくれた間に勧告されていたのか。
......。
何だか色々あるようですが、errata読んで第五版の翻訳版も書いてみますか。
概要: XMLの仕様書は、文字の規格としてUnicodeを少なからず頼っているので、XML 1.1の仕様書の中にもUnicode用語はしばしば出てきます。Combining CharacterとかCompos...
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という語は、文字通り「能動的に」結合する文字を指す。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
先行する文字に結合したりしない文字で、制御文字でも形式文字(フォーマット文字?)でもないもの。殆どのUnicode文字はBase Character。日本語では、主に「基底文字」と訳されるようだ。
参考 : Unicode 4.0.0 - Chapter 3 Conformance - 3.6 Combination - D13 Base character
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
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は錬金術が目指したもの、って感じかなあ(強引かも)。……ああ、核融合がする事って言った方が正確かな。
これはUnicode用語に見えて実はXML用語で、www.unicode.orgを"Composing Character"でGoogle検索してもヒットしない。将来的には出てくるかも知れないけど。日本語にすると……「合成文字」? うー、Composite Characterと被る。「XMLにおける合成文字」ってしとくか。あるいは開き直って「コンポージングキャラクタ」で通すか。
これはどちらかと言うとCombining Characterの変種らしい。次の何れかあるいは両方に当てはまるものがComposing Characterであるとされている。
意味的には「特殊な結合文字」辺りが的を射ている気がする。
参考 : Extensible Markup Language (XML) 1.1 (Second Edition) - composing character
これは形容詞。数学の「極限まで単純化された」辺りの意味からとったものだろう、と思う。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に拠れば、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
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
大体の場合、分解。(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
次のように遂行される、あるいは次のように遂行されたのと同じ効果を持つDecomposition。
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
A numeric value given to each combining Unicode character that determines with which other combining characters it typographically interacts.
らしい。
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
名詞句。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
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
「正規形C」らしいけど、これは固有名詞でいいような気もするなあ。具体的には、文字列SのNormalization Form Cは次の手順を踏むことで得られる(同じ結果が得られればこの通りでなくても良い)。
ははぁ、なるほど。やる事は(Primary Compositeの判定を除けば)実に単純明快だけど、ここまで辿り着くのは中々大変だなあ。
参考 : Unicode Standard Annex #15 UNICODE NORMALIZATION FORMS - R1. Normalization Form C、ものかの - Unicode正規化 その4
勿論「漢字」の事。ちょっと不思議に思って調べてみたら、The Japanese name for Han characters; derived from the Chinese word hànzì. Also romanized as kanzi.
だって。ははぁ、なるほど、それでUnicodeData.txtには漢字が入ってない訳。……って事はやっぱり、Unihan.txtの中なんだろうなあ。
でも、Unicodeの資料って、自分でXMLの仕様書に書いてある事を理解しようと思って色々調べてみても、結局翻訳する時には殆ど現れない事が多いんですよね。だからUnicodeなんて大嫌いだ。でもUnicodeが大好きです。
はあ、XML 1.1 Second Editionの翻訳はそろそろ3 Logical Structureに入ろうかという所。2.13 Normalization CheckingとかいうUnicode用語を臆面も無く使うセクションがあるからだ。
概要: 「整形式」とは何か XMLの仕様書には、"well-formed"とか"well-formedness"という単語が出てきます。英語では一般的な単語で、形容詞"well-formed"の原義は文字通り...
XMLの仕様書には、"well-formed"とか"well-formedness"という単語が出てきます。英語では一般的な単語で、形容詞"well-formed"の原義は文字通り「形の良い」といった所で、言語学では転じて「適格な」「(理論・体系に)合致した」となり、名詞"well-formedness"は「well-formedである事」らしいのです(手許の電子辞書のジーニアス英和大辞典に拠ると)。XMLを扱う日本語の文書では、"well-formedness"の訳語は「整形式」(「整」+「形式」)と相場が決まっているようです。よって今書いている翻訳版でもこの訳語を使う事にしています。一方、"well-formed"の訳語は「整形式の」が主流なようです。これは、「整形式」という語の組成から──「形式」は名詞であり、そこに形容詞的働きをする(名詞を修飾する)「整」が付いているから──「整形式」は名詞句(あるいは、固有名詞? ちなみに、ここでは「句」をphraseの意味で使います)であり、ここから形容詞を作る為格助詞「の」を使って「整形式の」となったのでしょう。「の」から転じたらしい「な」にも格助詞として似たような意味はあるようですが、「形式」に付くと変な感じがします(恐らく、殆どの人が「新しい形式な文書」や「古い形式な書類」という表現を不自然と感じるでしょう)。
さて、言語学なんてかじった事もありませんが、この記事では(多分)中学校で習った日本語の文法知識と日本人としての経験を基に、僭越ながらこの「整形式」について、というより「整形式」がきっかけとなって考えた事を書き下してみようと思います。
形容詞句「整形式の」は、"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"の主な語義とほぼそのまま対応します。「形」は勿論性質ではありません。しかし、「この文書は新しい形式だ。」と言う事もあります。これは、「この文書は新しい形をしている。」「この文書は新しい形式を持っている。」というように解釈される事を意図した、言わば省略された文です。「文書」が「新しい形式」そのものではないでしょう。また、「新しい形式の文書を解析できるプログラムはまだ無い。」という文も自然に聞こえます。これも「新しい形をしている文書を解析できるプログラムはまだ無い。」などのように解釈される事を期待しているのでしょう。でも、助詞「な」を使って「新しい形式な文書を解析できるプログラムはまだ無い。」とした文書は奇妙です。文法的には助詞「な」は助詞「の」の転なので問題無いのでしょうが、普通は使いませんよね。助動詞「だ」の連体形「な」を使ったと考えても、「新しい形式な文書を解析できるプログラムはまだ無い。」は変です。「形式」は性質ではないので、「この文書は新しい形式だ。」という文は「この文書」が「新しい形式」という状態ならぬ状態にある事を示すのではなく、「この文書」が「新しい形式」という「もの」そのものを示すのでもなく、「この文書は新しい形式を持つものだ。」という文の省略形である事を示すからです。名詞「形式」と助動詞「だ」は繋がっているように見えて、実は繋がっていないのです。だから、あたかも直接繋がっているかのように助動詞「だ」を活用すると変なのでしょう。
「整形式」の場合も「形式」と同じように、「その文書は整形式である。」と言った場合、「その文書は整った形をしている。」「その文書は整った形式を持っている。」と解釈されるべきもの、つまり「その文書は整形式を持つものだ。」という文の省略形である事を示唆するでしょう。そして、「整形式の文書」と言う時は、「整った形をした文書」「整った形式を持つ文書」と読まれる事を期待します。……あれ、では何にも問題は無い?
いや、いや、一つあります。「整形式」を「形式」の一つとしてしまえば、その訳語は明らかに"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の仕様書って流し読みとか拾い読みには向いてないなあ。と、通し読みしながら思った。
概要: What's New in Internet Explorer 7.0というページを見つけたので、気になる点をいくつか書き出してみます。 HTML 4.01のABBR要素のサポート ...
What's New in Internet Explorer 7.0というページを見つけたので、気になる点をいくつか書き出してみます。
HTML 4.0.1 Support: Internet Explorer 7 recognizes the ABBR tag from HTML 4.0.1.
……って今頃?! まぁ、無いよりましですけど。勿論can be styled with CSS
です。これで、心置きなくacronymをabbrに置き換える事ができますね。尤も、これはこのページを見るより前に気がついて、もうスタイルシートの方は書き換えてましたが。
それと、object要素のネストもサポートって書いてありますが、……逆に<object data="/image/valid-xhtml11" type="image/png">Valid XHTML 1.1</object>とかが解釈できなくなってませんか(内容が描画される)? 気のせい? IE6では(無様な)枠付きでも、表示だけはしてたのに。まぁ、<object data="/image/valid-xhtml11" type="image/png"><img src="/image/valid-xhtml11" alt="Valid XHTML 1.1"/></object>とやればIEでも問題無くなったので、いいのはいいんですが、ブラウザの退化によって記述が進化するというのも微妙ですねえ。
Portable Network Graphics (PNG): Internet Explorer 7 adds support for Alpha Channel Transparency to PNG.
ほうほう、これはいいですね。ミケネコ研究所のPNGのページによれば、Operaはバージョン7からサポートしているし、Mozillaの前身Netscapeもバージョン7でサポートしているようなので、Mozilla2でもきっと大丈夫でしょう。これで、Windowsブラウザ御三家ではアルファチャンネル付きのPNGイメージを堂々と使えるようになった訳ですね。祝着、祝着。
Cascading Style Sheets (CSS) Updates: Internet Explorer 7 features improved CSS, Level 2 (CSS2) support for Selectors (first-child, adjacent, attribute and child selectors) and Fixed Positioning.
って言われても、IE6まではサポートされていなかったので馴染みが無いセレクタです。ちょっと調べてみましょう。
子孫セレクタ(Descendant Selectors)と似ていますが、子だけ(直接の内容要素だけ)に適用されるセレクタです。a > bのような書き方をし、aの子のbにマッチします。適用対象もbです。
first-child擬似クラス(first-child Pseudo Class)は、子セレクタと一緒に使い、a > b:first-childのように書きます。aが幾つかbを子に持っていても、適用されるのは最初のbだけです。
正確に言うと、隣接兄弟セレクタです。同じ親を持つ要素で、しかも隣接しているときにのみ適用されます。a + bのように書き、aとbが同じ親を持っていて、bが(コメントやテキストを除外すると)aの直後に続いている場合、bにマッチします。つまり、適用対象はbです。
クラスセレクタ(Class Selectors)はIE6まででもサポートしていましたが、これはもっと一般的なものです。スクウェアブラケットで挟まれた中に、属性名と属性値を指定することができ、しかも幾つも条件を重ねられます。
例えばa[title]で、title属性を(値は何でもいいから)持っているa要素にマッチします。a[rel="alternate"]では、rel属性が"alternate"であるa要素にマッチします。a[rel~="bookmark"]なら、rel属性が"alternate bookmark"であるなど、bookmarkという(スペースで区切られた)「単語」を持つa要素にマッチします。最後に、a[rel~="alternate"][hreflang|="en"]なら、rel属性が"alternate"単語を持ち、言語が英語であるa要素──hreflang属性の値が"en"、"en-US"、"en-UK"などであるa要素──にマッチします。
KatsuさんのCSS2リファレンスの対応状況によれば、MozillaやOperaでも大丈夫そうなので、これも堂々と使えるようになったものの中の一つという訳ですね。
しかし、この対応状況のページ、仮名・漢字遣いやデザインが言葉 言葉 言葉に似ていたので、てっきり同じ方かと思ったら、違うんですね。
概要: げげげぇ(何て汚い言葉遣いなんだ)。XSLT 2.0とXPath 2.0が2007-01-23に勧告されていますよ! W3Cの新着情報はRSSでSyndicateしてたのに、見落とすとは……。何の為に...
げげげぇ(何て汚い言葉遣いなんだ)。XSLT 2.0とXPath 2.0が2007-01-23に勧告されていますよ! W3Cの新着情報はRSSでSyndicateしてたのに、見落とすとは……。何の為にチェックしてるんだか……はぁ。
ま、それはともかく待望のXSLT 2.0とXPath 2.0ですね。風の便りに聞いた所によると、XPathでは結果ツリーフラグメントをノードセットに再評価する事が仕様で定められるとの事でしたが、さて……
ほう、結果ツリーフラグメント(Result Tree Fragment)は消えたんですね(The result tree fragment data-type is eliminated.
)。変数結合要素(と訳すのか? Variable-binding Element。xsl:variable要素とxsl:param要素の事)の値は、全部テンポラリツリーになるようですね(A variable-binding element with content (and no as attribute) now constructs a temporary tree, and the value of the variable is the root node of this tree.
)。テンポラリツリー(Temporary Tree)はソースツリーでも最終結果ツリーでもない全てのツリーで、ソースツリー(Source Tree)というのはXSLT変換の入力で与えられるツリー(*.xmlファイルなんかで記述するツリーの事ですね)、最終結果ツリー(Final Result Tree)というのは最終出力にそのまま吐かれるツリーの事のようです。そして、テンポラリツリーはノードセットとしても扱える! いやあ、素晴らしい。これで、仕様書も言っているように独自実装のnode-set関数は消え去るでしょう。そして、MozillaやOperaでも僕の望むようなXSLT変換ができるようになるでしょう! ……って、Operaはまだdocument関数すら実装されていないんでした。……今、Opera 9.10にバージョンアップしてみましたが、Changes logにも書いてないし、実験しても駄目でした。
XSLT 2.0とXPath 2.0に対応するユーザーエージェントはいつ頃登場するでしょうか。IEが一番早そうですかね。今から楽しみです。
概要: Opera 9もXSLTプロセッサが実装されたようですが、Mozilla Firefoxでも実装されているんですね。Netscapeの日本法人が撤退してバージョンアップが止まっているということを(今更...
Opera 9もXSLTプロセッサが実装されたようですが、Mozilla Firefoxでも実装されているんですね。Netscapeの日本法人が撤退してバージョンアップが止まっているということを(今更)知ったので、Firefox 2.0を入れてみましたが、…うん、これはなかなか。フォント周りも強くなってるし。
Firefox 2のXSLTプロセッサはXSLT 1.0のdocument関数が使えるのはいいんですが、結果ツリーフラグメント(Result Tree Fragment)をノードセットとして評価することができないようです。
そもそも結果ツリーフラグメントって何かというと、大雑把に言えばxsl:variable要素やxsl:param要素の内容としての値です。例えば、
<xsl:variable name="result"> <level>3</level> <number>1-1</number> </xsl:variable>
上記のような変数resultがあった場合、$resultはlevelとnumberの二つのノードを持つノードセットのように見えますが、これはノードセットにはなりません。結果ツリーフラグメントと呼ばれます。結果ツリーフラグメントに対しては文字列操作しか許されず、勿論/や//、[]などのノードセットに対してのみ使える演算子は使えません。ただ、xsl:copy-of要素のselect属性で結果ツリーフラグメントを値に持つ変数を指定すると(<xsl:copy-of select="$result"/>のようにすると)、あたかもそれがノードセットであるかのように振る舞います。
別の例を見てみましょう。対象とするXML文書の子孫にbodyという要素があって、body要素は幾つかのsection要素を子に持っているとします(うちのXML文書のスタイルです)。この時、次のXSLTコード(断片というべき?)は許されます:
<xsl:variable name="body" select="//body"/> <xsl:for-each select="$body/section"> <!-- 何らかの処理 --> </xsl:for-each>
しかし、次のようにすると誤りです。
<xsl:variable name="body"> <xsl:copy-of select="//body"> </xsl:variable> <xsl:for-each select="$body/section"> <!-- 何らかの処理 --> </xsl:for-each>
先程も言った通り、xsl:variable要素などの内容にしてしまうと、それがなんであれ結果ツリーフラグメントになるのです。数値を書いても文字列を書いても何でもかんでも結果ツリーフラグメントに。一方で、select属性で値を与えると、式の型と同じになります。ノードセットならノードセットに、数値なら数値に、文字列なら文字列に、ブーリアンならブーリアンに。そんな訳で、前者の$bodyはノードセットで、後者の$bodyは結果ツリーフラグメントなのです。ああ無情。
しかしながら、xsl:variableの内容として書いてもノードセットとしてみてもらいたいことは少なくないわけで、──例えば変数の値にa要素を幾つか書いておいて、あとでそれをxsl:for-eachで処理するとか、テンプレートの戻り値(戻り結果ツリーフラグメント?)が複雑になる場合、さっきのlevelやnumberのように要素で区切って返すとか(Cで言うと構造体を返す感じ)。そんな時のために、IEやSablotron(PHPとかでも使える、何かの素粒子か加速器みたいな名前のXSLTプロセッサ)などでは次のような技巧が使えます:
<xsl:variable name="result"> <level>3</level> <number>1-1</number> </xsl:variable> <xsl:variable name="result-node" select="$result"/>
これで、$resultは結果ツリーフラグメントですが、$result-nodeは(select属性で値を与えているので)ノードセットになります。……って、こんなんでいいなら最初っからxsl:variableの内容でもノードセットにしろッ! と叫びたくなりますが、まぁXSLT 1.0の仕様書に「内容だったら結果ツリーフラグメントと見なせ」って書いてあるので、なんとも……。ちなみに独自拡張のnode-set関数でもいいようです。
IE 6でもこの技巧が使えたので、数年前からずっとこの方法を愛用しているのですが、どーもFirefoxのXSLTプロセッサはこれが駄目らしい。仕様書に書いてないからバグではないんだけど、悲しい。Opera 9はこの方法が使えるけど、document関数がまだ実装されてないし…(近々実装されるという噂だけはあるけども)。うーん。結局IE6以降でなければサーバーサイドで変換するしかないようで。はぁ、がっくし……
