計算機とその周辺: What I Talk About When I Talk About Computers: Semantics

ラベル Semantics の投稿を表示しています。すべての投稿を表示

2009年7月26日日曜日

2009年7月11日土曜日

意味論という言葉も厄介じゃないかなぁ。

まず、意味論として国語辞典、Semanticsとして英和辞書、英英辞書をみてももやもやしてわからない。これは例えば数学(Math)を国語辞典や英英辞典で見てもそれを理解できないのと同じことなのかな、と理解しておけばいいのだろうか。

でも、言葉としてのスケールが違うような?とも思う。

* この文のセマンティクスはどう決まっていますか?

というのが意味がありそうだと思えても、

* この文の数学はどう決まっていますか?

というのは無意味な質問に思える。数学と比してセマンティクスという言葉がスケールが小さいものにも適用できる言葉であるならば、辞書や辞典にもっと分かりやすい説明があってよいと思うのだが。。。

と考えていた。で、AIMAを読むとわかるのかわからないのか。

これが、わかるのだ。

x + y = 4 という文でAIMAは論理言語の意味論を説明している。それを私なりに咀嚼して書いてみよう。

まず、x + y = 4という文をみて我々はこの文を頭の中に入れることができる。ただしそれは+ x y 4 =であっても同じである。それらに比してx + y = 4というのは特別である。何故特別かというとそれはこの文に対する統語論を我々は学校で「算数」という名のもとに教えてもらっているからである。逆に言うと、+ x y 4 =は、「算数」という統語論では規則違反である。
「算数」という統語論の中には、+ = 1 2 3 4などのconstantsとx yなどのvariablesが定義されており、文の構成素材として使用することができることも教えてもらっている。
xとyはvariablesなので、このx + y = 4という文に対してモデル(別名で可能世界)を考えることができる。例えば、「xが1、yが2であるようなモデル(世界)」「xが2、yが2であるようなモデル(世界)」などなど。これは「算数」ではconstansが無限にあることによって、モデルの数も無限になる。ここで大事なのは、ここでモデル云々の考え方は、「算数」の中で定義されているのではなく、論理言語一般の考え方ということだ。別の言葉でいうと、「算数」というものを論理言語の考え方で捉えて語っているのがこの文章であるということ。
さて、我々は x + y = 4という文において、「xが1、yが2であるモデル」ではこれが偽であり、「xが2、yが2であるモデル」ではこれが真であると言われると、それは合点がいくような気持になる。それはひとつの観点では、+ = 1 2 3 4などのconstansの意味を知っているからそれと照し合わせてそういう気持になるとも言えるが、そうすると意味って何よ?ということになってここが曖昧である。
そこを考えると我々がここで「意味」と認識しているものは、結局、
x + y = 4 という文は、
「xが1、yが1であるモデル」にて偽、
「xが1、yが2であるモデル」にて偽、
「xが1、yが3であるモデル」にて真、
「xが2、yが1であるモデル」にて偽、
「xが2、yが2であるモデル」にて真、
...
ということ自体が展開された形での「意味」そのものではないか、ということになる。
すなわち、我々が「算数」という名称で教わったものは、「算数」としての文の書き方と、「算数」としてそれら文がどのようなモデルにて真偽値を取るかという対応であるということになる。この前者が「算数」の統語論(Syntax)であり、「後者」が意味論(Semantics)である。

スタートレックは異文化に対するイマジネーションに満ちているのでスタートレックのアナロジーを再度やってみよう。

Mr.スポック曰く、バルカン星では子供のころに「バルカニーナ」を教わる。
バルカニーナの統語論は、constansとして+ = 1 2 3 4であり、variablesとしてxとyがある。もちろん文の構造を決める他の文法規則もある。それら規則によると、x + y = 4は文とみなせるが、+ x y 4 = は違反であり文とみなせない。
バルカン星人は、 x + y = 4という文において、「xが2、yが2であるモデル」ではこれが偽であり、「xが1、yが1であるモデル」ではこれが真であると言われると、それは合点がいくような気持になる。それはひとつの観点では、+ = 1 2 3 4などのconstansの意味を知っているからそれと照し合わせてそういう気持になるとも言えるが、そうすると意味って何よ?ということになってここが曖昧である。
そこを考えるとバルカン星人がここで「意味」と認識しているものは、結局、
x + y = 4 という文は、
「xが1、yが1であるモデル」にて真、
「xが1、yが2であるモデル」にて偽、
「xが1、yが3であるモデル」にて偽、
「xが2、yが1であるモデル」にて真、
「xが2、yが2であるモデル」にて偽、
...
ということ自体が展開された形での「意味」そのものではないか、ということになる。
すなわち、バルカン星人が「バルカニーナ」という名称で教わったものは、「バルカニーナ」としての文の書き方と、「バルカニーナ」としてそれら文がどのようなモデルにて真偽値を取るかという対応であるということになる。この前者が「バルカニーナ」の統語論(Syntax)であり、「後者」が意味論(Semantics)である。

これで明確になったと思うけど駄目おしを。

Dr.マッコイ：「x + y = 4」という暗号通信をクリンゴンの偵察挺が送信していたらしい。これはどういう意味だろう。

Mr.スポック：それは意味論により異なりますね。地球人はそれを算数の意味論に従っていると盲目的に解釈しがちですが、それは理性的ではありません。

Dr.マッコイ：「x + y = 4」に理性もへったくれもあるか！

Mr.スポック：感情的にならないでください。実際にバルカン星人にとっては、その文が適格である統語論でもっとも最初に習うのは「バルカニーナ」であり、「バルカニーナ」の意味論は地球人の「算数」の意味論とは違います。さらにバルカン星人の知識の中にある別の12の統語論においても「x + y = 4」を適格と見做すことができますがね。統語論と意味論をごちゃごちゃにして初等教育を行う地球人とは、バルカン星人は大きく異なるのです。バルカン星人は常に統語論と意味論を分けて学習します。

Dr.マッコイ：君だって地球人の血が半分流れてるじゃないか！

閑話休題。

x + y = 4 の意味論を算数とする

という表現がAIMAでもあるのですが、これはちょっとリスキーなんですね。私は今までこれがわからなかった。より混乱が少いのは、

x + y = 4 の意味論を、算数という名称で君や私が習った意味論にする。(統語論が算数と一致しているということは前提としている)

という表現である。

ああ、すっきりした。

2009年7月7日火曜日

【LPN】8 More Definete Clause Grammars


* 8 More Definete Clause Grammars
 - defineteということはindefineteもあるのかどうか、
   というのが気になる。
** 1 Extra Arguments
 - Context free grammars with features
 - 代名詞の導入。
s --> np_subject,vp.

np_subject --> det,n.
np_object --> det,n.
np_subject --> pro_subject.
np_object --> pro_object.

vp --> v,np_object.
vp --> v.

det --> [the].
det --> [a].

n   --> [woman].
n   --> [man].

v   --> [shoots].

pro_subject --> [he].
pro_subject --> [she].
pro_object --> [him].
pro_object --> [her].

 - lexicon : 辞書
 - 代名詞をいれただけで、これだけ文法を書きかえな
   ければいけないのはうまくない。また、代名詞と名
   詞は多くの性質を共有しているのにそれをまったく
   別に定義する、というのもうまくない。
 - これらをうまくやるのがextra arguments。

s --> np(subject),vp.

np(_) --> det,n.
np(X) --> pro(X).

vp --> v,np(object).
vp --> v.

det --> [the].
det --> [a].

n   --> [woman].
n   --> [man].

v   --> [shoots].

pro(subject) --> [he].
pro(subject) --> [she].
pro(object) --> [him].
pro(object) --> [her].

 - npにfeaturesを追加した。
 - DCG with argumentsは、言語処理のための最新のツー
   ルではない。しかし単なるおもちゃでもない。相当に
   洗練された文法を記述できる。

 - Building parse tree
 - うーん、

   s(np(det(a),n(woman)),vp(v(shoots))).

   (s (np (det a) (n woman)) (vp (v shoots)))

   S式の方が見易いと思うんだけどなぁ。まあそれは
   PAIPで。

 - extra argumentsを利用してparserにする。

s(s(NP,VP)) --> np(NP),vp(VP).

np(np(DET,N)) --> det(DET),n(N).

vp(vp(V,NP)) --> v(V),np(NP).
vp(vp(V)) --> v(V).

det(det(the)) --> [the].
det(det(a)) --> [a].

n(n(woman))   --> [woman].
n(n(man))   --> [man].

v(v(shoots))   --> [shoots].

 - DRYではないが、書けるぞ、という感じ。
 - extra argsは、semantic representationsを構築す
   るのにも便利につかえる。
 - semantic representationsはformal languagesによっ
   て記述される。例えば、
   - first order logic
   - discourse representation structures
     : 談話言語表示理論
   - a database query language
 - これらはcompositonaryに構築される。
 - というのは単純にそれぞれの単語の意味を結合する
   だけではなくて、parse treeの構造をみつつ、意味
   を構築していく。

 - Beyond context free language
 - DCGはCFG以外の文法も記述できる。
 - 例えば、{a^nb^nc^n\{e}}。

s(Count) --> ablock(Count),bblock(Count),cblock(Count).
ablock(0) --> [].
ablock(succ(Count)) --> [a],ablock(Count).
bblock(0) --> [].
bblock(succ(Count)) --> [b],bblock(Count).
cblock(0) --> [].
cblock(succ(Count)) --> [c],cblock(Count).

** 2 Extra Goals
 - DCGの右側ではPrologの機能を使える。
 - それはextra goalsとして、であり、{}で囲む。

s --> ablock(Count),bblock(Count),cblock(Count).
ablock(0) --> [].
ablock(NewCount) --> [a],ablock(Count),
        {NewCount is Count + 1}.
bblock(0) --> [].
bblock(NewCount) --> [b],bblock(Count),
        {NewCount is Count + 1}.
cblock(0) --> [].
cblock(NewCount) --> [c],cblock(Count),
        {NewCount is Count + 1}.
 - なお、これはrecogniserとしてのみ使える。

 - Separating rules and lexicon
 - Extra Goalsの有用な応用として文法と辞書の分離が
   ある。
 - 自然言語のlexiconsは巨大になるので実戦においても
   メリットがある。
 - Prologはfirst argment indexingを実施しているの
   で、効率もよくなる。
** 3 Concluding Remarks
 - DCGはturing-complete。
 - "all top-down parsers loop on left-recursive
   grammars." なるほど。
 - なお、DCGという記法に何か問題があるわけではない。
   それのPrologの解釈(実行する手続き)に注意が必要
   だということだ。syntaxとsemanticsの分離というこ
   とか。
** 4 Exercise
 - Exercise 8.1.

s --> np(X),vp(X).

np(X) --> det(X),n(X).
vp(X) --> v(X),np(_).
vp(X) --> v(X).

det(plur) --> [the].
det(sing) --> [the].
det(sing) --> [a].

n(sing) --> [woman].
n(sing) --> [man].
n(sing) --> [apple].
n(sing) --> [pear].
v(plur) --> [eat].

n(plur) --> [women].
n(plur) --> [men].
n(plur) --> [apples].
n(plur) --> [pears].
v(sing) --> [eats].

 - Exercise 8.2.

kanga(V,R,Q,A,C) :-
        roo(V,R,A,B),
        jumps(Q,Q,B,C),
        marsupiral(V,R,Q).

** 5 Practical Session

   - 1.

lex(woman,n,sing).
lex(man,n,sing).
lex(apple,n,sing).
lex(pear,n,sing).
lex(women,n,plur).
lex(men,n,plur).
lex(apples,n,plur).
lex(pears,n,plur).

lex(a,det,sing).
lex(the,det,sing).
lex(the,det,plur).

lex(eat,v,plur).
lex(eats,v,sing).

lex(he,pro,sing,subj).
lex(she,pro,sing,subj).
lex(him,pro,sing,obj).
lex(her,pro,sing,obj).


s(s(NP,VP)) --> np(NP,X,subj),vp(VP,X).

np(np(DET,N),X,_) --> det(DET,X),n(N,X).
np(np(PRO),X,Y) --> pro(PRO,X,Y).
vp(vp(V,NP),X) --> v(V,X),np(NP,X,obj).
vp(vp(V),X) --> v(V,X).

det(det(Word),X) --> [Word],{lex(Word,det,X)}.
n(n(Word),X) --> [Word],{lex(Word,n,X)}.
v(v(Word),X) --> [Word],{lex(Word,v,X)}.
pro(pro(Word),X,Y) --> [Word],{lex(Word,pro,X,Y)}.
     
   - 2.
/* lexicon */
lex(woman,n,sing,third).
lex(women,n,plur,third).
lex(man,n,sing,third).
lex(men,n,plur,third).
lex(apple,n,sing,third).
lex(apples,n,plur,third).
lex(pear,n,sing,third).
lex(pears,n,plur,third).

lex(a,det,sing).
lex(the,det,sing).
lex(the,det,plur).

lex(eat,v,plur,third).
lex(eats,v,sing,third).
lex(eat,v,plur,first).
lex(eat,v,sing,first).
lex(eat,v,plur,second).
lex(eat,v,sing,second).

lex(i,pro,sing,subj,first).
lex(me,pro,sing,obj,first).
lex(you,pro,sing,subj,second).
lex(you,pro,sing,obj,second).
lex(he,pro,sing,subj,third).
lex(him,pro,sing,obj,third).
lex(she,pro,sing,subj,third).
lex(her,pro,sing,obj,third).

lex(in,prep).
lex(on,prep).
lex(under,prep).
lex(over,prep).

lex(small,adj).
lex(big,adj).
lex(beautiful,adj).
lex(frightened,adj).
lex(fat,adj).
lex(tall,adj).

s(s(GNP,VP)) --> gnp(GNP,SP,subj,Person),vp(VP,SP,Person).

/* general noun phrases */
gnp(gnp(PRO),SP,SO,Person) --> pro(PRO,SP,SO,Person).
gnp(gnp(NP),SP,_,Person) --> np(NP,SP,_,Person).

/* noun phrases */
np(np(DET,NC),SP,_,Person) --> det(DET,SP),nc(NC,SP,Person).
np(np(NP,PP),SP,SO,Person) --> np(NP,SP,SO,Person),pp(PP).

/* noun cores */
nc(nc(N),SP,Person) --> n(N,SP,Person).
nc(nc(ADJ,NC),SP,Person) --> adj(ADJ), nc(NC,SP,Person).

/* preposition phrase */
pp(pp(PREP,GNP)) --> prep(PREP), gnp(GNP,_,obj,_).

/* verb phrases */
vp(vp(V),SP,Person) --> v(V,SP,Person).
vp(vp(V,GNP),SP,Person) --> v(V,SP,Person),gnp(GNP,SP,obj,_).

/* load lexicon */
det(det(Word),SP) --> [Word],{lex(Word,det,SP)}.
n(n(Word),SP,Person) --> [Word],{lex(Word,n,SP,Person)}.
v(v(Word),SP,Person) --> [Word],{lex(Word,v,SP,Person)}.
pro(pro(Word),SP,SO,Person) --> [Word],{lex(Word,pro,SP,SO,Person)}.
prep(prep(Word)) --> [Word],{lex(Word,prep)}.
adj(adj(Word)) --> [Word],{lex(Word,adj)}.


  えっと、、、、
  形容詞を問題文のように入れると無限ループが発
  生するので、いろいろ支障があると思うのだが。形容
  詞は2個までとか制限をつけるのかなぁ

最後の課題が結構タフだった。
こつこつ。

2009年2月5日木曜日

XMLを扱う (その19) [The little XMLer ?]

XMLすらまともに理解していない。。。
XMLを理解するのにすら時間がかかる。。。
ということで結構へこんでいる。

とりあえず多少なりとも理解するためにThe little schemer風味で自分なりに整理してみた。まだ、抜け漏れ間違いを含んでいると思うけど。

Norvigはプログラミングを学ぶには10年かかると書いていたが、本当に10年かかりそうだ。

いかん。ポジティブ。こつこつ。


- "Extensible Markup Language (XML) 1.0 (Fourth Edition)"とは、XML文書の仕様を定める文書である。
  この文書をXML仕様書と呼ぶ。
  - XML文書を処理するa software moduleであるXML processorの振舞いの一部も定めている。
  - XML processorとapplication(これもa software module)の関係の一部も定めている。

- XML documents (XML文書)とは、text(a sequence of chracters)である。
  - charactersは、ISO/IEC 10646:2000 (Unicode 2.0)で定義されたcharactersである。
  - textがXML文書であるということは、それがXML文書の構文規約に準拠していることが必要である。
    それをwell-formed云々といったりする。
    しかし、言語に構文がありそれに従っているものがその言語に属する文であることはあたりまえという観点をこの資料では採用する。
  - XML「文書」という名称ではあるが、OS上のファイルである必要はない。
  - 本資料では、Allegro Common LispのeliのREPL上の文字列にてXML文書を表現していることにする。

- XML文書のsemanticsは2段構造を取る。
  まず第一のsemanticsはXML仕様書にて定義されているものであり、XML processorがどう振る舞うかという観点で記述されている。
  例えばXHTMLについてはどうだろう。
  - XML processorはXHTML文書を受取り、pysical structure(entities)に関する処理を行う。
    これはCのマクロをプリプロセスするのに似ている。
  - またXML processorはXHTML文書を受け取ると、logical structureに関する処理を行う。
    これは、well-formedの確認、validの確認、processor instructionの解釈などを含む。
  - 以上がXML processorによる(おける)semanticsである。
    XHTML文書がどのように描画されるかというsemanticsはapplicationである例えばWeb browserによって(において)定義される。



インデントしている文章で言及している文字列は、一階層上の文字列の部分文字列とする。



- "a"

  - "a"はCLの文字列である。
  - "a"はXML文書ではない。


- "<a/>"

  - "<a/>"はCLの文字列である。
  - "<a/>"はXML文書である。

  - "<a/>"はentityである。
  - このXML文書は単一のentityで構成されている。
  - "<a/>"はdocument entityである。

  - "<a/>"はan elementである。
  - "<a/>"のelement nameは"a"である。
  - "<a/>"はan empty-element tagである。
  - nameが"a"というelementはcontentを持たない。

  - "<a/>"はMarkupである。character dataではない。
  - "<a/>"はdocument entityが含むparsed dataである。
    - このparased dataはMarkupのみから構成されている。


- "<a />"

  - これはXML文書である。
  - "<a />"は"a"というnameのelementである。


- "<a:b/>"

  - これはXML文書である。
  - "<a:b/>"は"a:b"というnameのelementである。
  - ただし、XML namespaceをやる場合以外はこのnameは使うべきではない。


- "<a:b:c/>"

  - これはXML文書である。
  - "<a:b:c/>"は"a:b:c"というnameのelementである。
  - ただし、XML namespaceとしては異常であるのでこのnameは使うべきではない。


- "<:a/>"

  - これはXML文書である。
  - "<:a/>"は":a"というnameのelementである。
  - ただし、XML namespaceとしては異常であるのでこのnameは使うべきではない。


- "<a:/>"

  - これはXML文書である。
  - "<a:/>"は"a:"というnameのelementである。
  - ただし、XML namespaceとしては異常であるのでこのnameは使うべきではない。


- "<a b/>"

  - これはXML文書ではない。


- "<0/>"

  - これはXML文書ではない。


- "<0a/>"

  - これはXML文書ではない。


- "<a0/>"

  - これはXML文書である。
  - "<a0/>"は"a0"というnameのelementである。


- "<あ/>"

  - これはXML文書である。
  - "<あ/>"は"あ"というnameのelementである。


- "<a/><a/>"

  - "<a/><a/>"はXML文書でない。


- "<a/><b/>"

  - "<a/><b/>"はXML文書でない。


- "<a></a>"

  - "<a><a/>"はXML文書である。

  - "<a></a>"はentityである。
  - このXML文書は単一のentityで構成されている。
  - "<a></a>"はdocument entityである。

  - "<a></a>"はan elementである。
  - "<a></a>"のelement nameは"a"である。
  - "<a></a>"はan empty-element tagではない。
  - "<a>"はa start tagである。
  - "</a>"はan end tagである。
  - nameが"a"というelementはcontentを持たない。

  - "<a></a>"はMarkupである。character dataではない。
  - "<a></a>"はdocument entityが含むparsed dataである。
    - このparased dataはMarkupのみから構成されている。


- "<a>x</a>"

  - "<a>x</a>"はentityである。
  - このXML文書は単一のentityで構成されている。
  - "<a>x</a>"はdocument entityである。

  - "<a>"は a start tagである。これはMarkupである。これはXML文書ではない。
  - "</a>"は an end tagである。これもMarkupである。これもXML文書ではない。
  - "<a>x</a>"は nameが"a"というan elementである。
  - name がaというelementのcontentは"x"である。
  - "x"はMarkupではない。character dataである。

  - "<a>x</a>"はdocument entityが含むparsed dataである。
    - このparased dataはcharacter dataでる。Markupのみから構成されている。


- "<a><b/></a>"

  - "<a><b/></a>"はentityである。
  - このXML文書は単一のentityで構成されている。
  - "<a><b/></a>"はdocument entityである。

  - "<a><b/></a>"は nameが"a"というan elementである。
  - nameが"a"というelementはcontentをもっている。そのcontentは"<b/>"である。

  - "<b/>"は name が "b"というan elementである。
  - "<b/>"は contentを持たない。
  - "<b/>"は、Markupである。character dataではない。

  - "a" elementの childは"b"elementである。
  - "b" elementの parentは"a"elementである。


- "<a><b/>x</a>"

  - "<a><b/>x</a>"はentityである。
  - このXML文書は単一のentityで構成されている。
  - "<a><b/>x</a>"はdocument entityである。

  - "<a><b/>x</a>"は nameが"a"というan elementである。
  - nameが"a"というelementはcontentをもっている。そのcontentは"<b/>x"である。


- "<?xml version="1.0"?>"

  - これはXML文書ではない。


- "<?xml version="1.0"?><a/>"

  - これはXML文書である。
  - "<?xml version="1.0"?>"はprologである。
  - "<?xml version="1.0"?>"はprocessor instructionではない。
  - "<?xml version="1.0"?>"はXML decralationである。


- "<!-- p -->"

  - これはXML文書ではない。


- "<!-- p --><a/>"

  - これはXML文書である。
  - "<!-- p -->"はprologである。
  - "<!-- p -->"はcommentである。
  - "<!-- p -->"はMarkupである。

- "<?MySoft verbose="on"?><a/>"

  - これはXML文書である。
  - "<?MySoft verbose="on"?>"はprologである。
  - "<?MySoft verbose="on"?>"はprocessor instructionである。
    - "MySoft"はPITargetである。


- " <a/>"

  - これはXML文書である。
  - " "はprologである。
  - " "はwhite spaceである。


- "<?xml version="1.0"?><!-- p --><?MySoft verbose="on"?> <a/>"

  - これはXML文書である。
  - "<?xml version="1.0"?><!-- p --><?MySoft verbose="on"?> "はprologである。


- "<a/><!-- p -->"

  - これはXML文書である。
  - "<!-- p -->"はcommentである。
  - "<!-- p -->"はprologではない。


- "<a/><?MySoft verbose="on"?>"

  - これはXML文書である。
  - "<?MySoft verbose="on"?>"はprocessor instructionである。
  - "<?MySoft verbose="on"?>"はprologではない。


- "<a/> "

  - これはXML文書である。
  - " "はprologではない。
  - " "はwhite spaceである。


- "<!DOCTYPE><a/>"

  - これはXML文書ではない。


- "<!DOCTYPE a [ <!ELEMENT a EMPTY> ]><a/>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<!DOCTYPE a [ <!ELEMENT a EMPTY> ]>"はprologである。
  - "<!DOCTYPE a [ <!ELEMENT a EMPTY> ]>"はdocument type decralationである。Standalone Document Declarationである。
    - Name "a"はroot element typeであり、XML文書のroot elementのnameと同じである必要がある。
    - "[ <!ELEMENT a EMPTY> ]"はinternal subsetである。
     - "<!ELEMENT a EMPTY>"はmarkup declarationである。
     - "<!ELEMENT a EMPTY>"はelement declarationである。
       - "a"はこのelement declarationで定義しようとしているelementのtypeである。
       - "EMPTY"はcontent specである。
       - "EMPTY"は、element type "a"はchildを持たない(contentを持たない)ことを現わす。

     
- "<!DOCTYPE a [ <!ELEMENT a ANY> ]><a/>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<!ELEMENT a ANY>"はelement declarationである。Standalone Document Declarationである。
     - "a"はこの文字列で定義するelementのtypeである。
     - "ANY"はcontent specである。
     - "ANY"は、element type "a"はcontentとして「何でもOK？」ということ。具体的には次のとおり。
       - character data (もちろんCDATA sectionも)
       - comments
       - processor instructions
       - child elements (この文書で定義されているものに限る)


- "<!DOCTYPE a [ <!ELEMENT a (b,c*)><!ELEMENT b EMPTY><!ELEMENT c EMPTY> ]><a><b/><c/><c/></a>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<!DOCTYPE a [ <!ELEMENT a (b,c*)><!ELEMENT b EMPTY><!ELEMENT c EMPTY> ]>"はelement declarationである。
     - "(b,c*)"はcharacter dataを含んでいない。
     - "(b,c*)"はcontent modelである。
      - "(b,c*)"、"c*"、"b"、"c"、"*"はcontent particlesである。


- "<!DOCTYPE a [ <!ELEMENT a (#PCDATA)> ]><a>x</a>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<!ELEMENT a (#PCDATA)>"はelement declarationである。
     - "a"はこのelement declarationで定義するelementのtypeである。
     - "(#PCDATA)"はcontent specである。
     - "a"は、Mixed typeである。
  - "<!ELEMENT a (#PCDATA)>"は、element type "a"はcontentとしてcharacter dataを持つことを現わしている。PCDATAのPはparased character dataのPであり、このネーミングは歴史的な理由による。


- "<!DOCTYPE a [ <!ELEMENT a (#PCDATA|b)*><!ELEMENT b EMPTY> ]><a><b/>x</a>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<!DOCTYPE a [ <!ELEMENT a (#PCDATA|b)*> ]>"はelement declarationである。
     - "a"はこのelement declarationで定義するelementのtypeである。
     - "(#PCDATA|b)*"はcontent specである。
     - "a"は、Mixed typeである。
  - "<!ELEMENT a (#PCDATA|b)*>"は、element type "a"はcontentとしてcharacter dataと"b"というnameのelementのミックスされたものを持つことを現わしている。


- "<!DOCTYPE a [ <!ELEMENT a (#PCDATA)> ]><a><![CDATA[<x>]]></a>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<![CDATA[<x>]]>"はCDATA sectionである。CDATA sectionの中では、Markupを表す文字列はMarkupではなく、chracter dataである。"<![CDATA["の後続において、MarkupであるとXML processorと認識するのは"]]>"であり、ここでCDATA sectionは終わる。CDATA sectionはcharacter dataが存在できる部分にはどこでも存在できる。



- "<a>&#12354;</a>"

  - これはXML文書である。

  - "&#12354;"はcharacter dataである。
  - "&#12354;"はcharacter referenceである。
  - "&#12354;"は"あ"である。
  - 12354はISO/IEC 10646における"あ"のcode pointの10進数表現である。


- "<a>&#x3042;</a>"

  - これはXML文書である。

  - "&#x3042;"はcharacter dataである。
  - "&#x3042;"はcharacter referenceである。
  - "&#x3042;"は"あ"である。
  - 3042はISO/IEC 10646における"あ"のcode pointである。(code pointはそもそも16進数)


- "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]><a>&h;</a>"

  - これはXML文書である。

  - "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]>"はprologである。
  - "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]>"はdocument type declarationである。
  - "<!ENTITY h \"hoge\">"はgeneral entityの定義である。

  - "&h;"はreferenceである。
  - "&h;"はentity referenceである。
  - "&h;"はcharacter referenceではない。
  - "&h;"はparameter entity referenceではない。

  - "&h;"は"hoge"である。

- "<!DOCTYPE a [ <!ENTITY h \"&#60;a/>\"> ]>&h;"

  - これはXML文書である。

  - "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]>"はprologである。
  - "<!DOCTYPE a [ <!ENTITY h \"&#60;a/>\"> ]>"はdocument type declarationである。
  - "<!DOCTYPE a [ <!ENTITY h \"&#60;a/>\"> ]>"はgeneral entityの定義である。

  - "&h;"はentity referenceである。
  - "&h;"は"<a/>"である。


- "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]><a>&h;</a>"

  - これはXML文書である。

  - "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]>"はprologである。
  - "<!DOCTYPE a [ <!ENTITY h \"hoge\"> ]>"はdocument type declarationである。
  - "<!ENTITY h \"hoge\">"はgeneral entityの定義である。

  - "&h;"はreferenceである。
  - "&h;"はentity referenceである。
  - "&h;"はcharacter referenceではない。
  - "&h;"はparameter entity referenceではない。

  - "&h;"は"hoge"である。


- "<!DOCTYPE a [ <!ENTITY h \"&#60;a/>\"> ]>&h;"

  - これはXML文書である。

  - "<!DOCTYPE a [ <!ENTITY h \"&#60;a/>\"> ]>"はprologである。
  - "<!DOCTYPE a [ <!ENTITY h \"&#60;a/>\"> ]>"はdocument type declarationである。
  - "<!ENTITY h \"&#60;a/>\">"はentity declarationである。
  - "<!ENTITY h \"&#60;a/>\">"はgeneral entityである。
  - "<!ENTITY h \"&#60;a/>\">"はinternal entityである。

  - "&h;"はentity referenceである。
  - "&h;"は"<a/>"である。


- hoge.xmlの中身は"<b/>"とする。
  - hoge.xmlは、XML文書である。


- "<!DOCTYPE a [ <!ENTITY s SYSTEM \"../aka/hoge.xml\"> ]><a>&s;&s;</a>"

  - これはXML文書である。

  - "<!ENTITY s SYSTEM \"../aka/hoge.xml\">"はentity declarationである。
  - "<!ENTITY s SYSTEM \"../aka/hoge.xml\">"はgeneral entityである。
  - "<!ENTITY s SYSTEM \"../aka/hoge.xml\">"はexternal entityである。
  - "\"../aka/hoge.xml\""はsystem identifierである。
    - system identifierはURIである。
  - hoge.xmlの中身である"<a><b/></a>"はexternal parsed entityである。

  - "&s;"はentity referenceである。
  - "<a>&s;&s;</a>"は"<a><b/><b/></a>"である。


- "<!DOCTYPE a [ <!ENTITY s SYSTEM \"http://www.examples.com/hoge.xml\"> ]><a>&s;&s;</a>"

  - これはXML文書である。

  - "<!ENTITY s SYSTEM \"http://www.examples.com/hoge.xml\">"はentity declarationである。
  - "<!ENTITY s SYSTEM \"http://www.examples.com/hoge.xml\">"はgeneral entityである。
  - "<!ENTITY s SYSTEM \"http://www.examples.com/hoge.xml\">"はexternal entityである。
  - \"http://www.examples.com/hoge.xml\"はsystem identifierである。
    - system identifierはURIである。
  - hoge.xmlの中身である"<a><b/></a>"はexternal parsed entityである。

  - "&s;"はentity referenceである。
  - "<a>&s;&s;</a>"は"<a><b/><b/></a>"である。


- "<!DOCTYPE a [ <!ENTITY s PUBLIC \"some public id\" \"http://www.examples.com/hoge.xml\"> ]><a>&s;&s;</a>"

  - これはXML文書である。

  - "<!ENTITY s PUBLIC \"some public id\" \"http://www.examples.com/hoge.xml\">"はentity declarationである。
  - "<!ENTITY s PUBLIC \"some public id\" \"http://www.examples.com/hoge.xml\">"はgeneral entityである。
  - "<!ENTITY s PUBLIC \"some public id\" \"http://www.examples.com/hoge.xml\">"はexternal entityである。
  - "\"some public id\""はpublic identifierである。
  - "\"http://www.examples.com/hoge.xml\""はsystem identifierである。
    - system identifierはURIである。
  - hoge.xmlの中身である"<a><b/></a>"はexternal parsed entityである。

  - "&s;"はentity referenceである。
  - "<a>&s;&s;</a>"は"<a><b/><b/></a>"である。


- "<!DOCTYPE a [ <!ENTITY % p \"hoge\"><!ENTITY g \"piyo %p;\" ]><a>&g;</a>"

  - これはXML文書である。

  - "<!DOCTYPE a [ <!ENTITY % p \"hoge\"><!ENTITY g \"piyo %p;\" ]>"はprologである。
  - "<!DOCTYPE a [ <!ENTITY % p \"hoge\"><!ENTITY g \"piyo %p;\" ]>"はdocument type declarationである。
  - "<!ENTITY g \"piyo %p;\" ]>"はgeneral entityの定義である。
  - "<!ENTITY % p \"hoge\">"はparameter entityの定義である。

  - "%p;"はreferenceである。
  - "%p;"はparameter entity referenceである。
  - "%p;"はcharacter referenceではない。
  - "%p;"はentity referenceではない。

  - "%p;"は"piyo"である。
 
  - "&g;"はreferenceである。
  - "&g;"はentity referenceである。
  - "&g;"はcharacter referenceではない。
  - "&g;"はparameter entity referenceではない。

  - "&g;"は"piyo hoge"である。


- "<!DOCTYPE a [ <!ENTITY % an \"ANY\"><!ELEMENT a %an;> ]><a/>"

  - これはXML文書である。
  - このXML文書はvalidである。
  - "<!ENTITY % an \"ANY\">"はparameter entityの定義である。
  - "<!ELEMENT a %an;>"は"<!ELEMENT a ANY>"である。


- "<!DOCTYPE a [ <!ENTITY % cm \"a (b,c*)\"><!ELEMENT %cm;><!ELEMENT b EMPTY><!ELEMENT c EMPTY> ]><a><b/><c/><c/></a>"

  - これはXML文書である。
  - このXML文書はvalidである。


- hoge.dtdの中身は"<!ENTITY a ANY>"とする。
  - hoge.dtdは、XML文書ではない。


- "<!DOCTYPE a SYSTEM \"aka/hoge.dtd\"><a/>"

  - これはXML文書である。
  - これはvalidなXML文書である。

  - "<!DOCTYPE a SYSTEM \"aka/hoge.dtd\">"はdocument type decralationである。
    - "SYSTEM \"aka/hoge.dtd\""はExternal IDである。
    - "\"aka/hoge.dtd\""はsystem identifierである。
      - system identifierはURIである。
    - hoge.dtdの中身はexternal subsetである。


- "<!DOCTYPE a PUBLIC \"hoge\" \"aka/hoge.dtd\"><a/>"

  - これはXML文書である。
  - これはvalidなXML文書である。

  - "<!DOCTYPE a PUBLIC \"hoge\" \"aka/hoge.dtd\">"はdocument type decralationである。
    - "PUBLIC \"hoge\" \"aka/hoge.dtd\""はExternal IDである。
    - "\"hoge\""はpublic identifierである。
    - "\"aka/hoge.dtd\""はsystem identifierである。
      - system identifierはURIである。
    - hoge.dtdの中身はexternal subsetである。



補足的なことたち。


- elementがわかればattributeは難しくないので、割愛した。

- "xml:space"というattributeは":"があるがXML namespaceの":"ではない。
  - "default"または"preserve"の値をとりうる。
  - どんなelementにもつけることができる。
  - validにするには、このattributeを自分でdocument type declarationで定義する。
  - "default"の場合は、while spaceの取り扱いがXML processorのデフォルトになる。
  - "preserve"の場合は、while spaceを削除せずにそのままcharacter dataとする。

- "xml:lang"というattributeは":"があるがXML namespaceの":"ではない。
  - どんなelementにもつけることができる。
  - validにするには、このattributeを自分でdocument type declarationで定義する。

- external entitiesには、"<?xml encoding='utf-8'?>"などのtext declarationを冒頭に付けるべきである。

- document type declaration external subsetにおいて、または、external parameter entitiesにおいて、conditional sectionsを利用できる。これはCにおけるifdefマクロみたいなものである。例は次のとおり。

"
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>
"

2009年1月31日土曜日

XMLを扱う (その11) [Common Lisp][Unicode]

ワークフロ-の続き。


 cxml-stpから。

 この際だから、cxmlのDOMに立ちもどって確認する。

 http://common-lisp.net/project/cxml/dom.html

 をみる。

 IDL/Lisp mappingというのはOMGが定めたもので、

 http://www.omg.org/docs/formal/00-06-02.pdf

 これ。Franzが作成支援したようだ。

 さて、cxml-stpが主張しているのは、

 ** DOMはIDLをつかって規程されている。
 ** IDL/LISP mappingはOMGで標準化されている。
 ** だからといってDOM/LISP mappingが標準化されているとはいえないぜ。
 ** なので、IDL/LISP mappingに従わず、俺流 mappingをするぜ。

 ということ。まあ、それはそうだ。

 characters/strings instead of runes/rods って何だろ？

 調べる。Unicodeに対応していない Lisp処理系にてUnicodeを扱うものな感
 じ。

 さらに調べる。closure-common packageで定義されているようだ。

 --- runes.lisp ---
 (deftype rune () '(unsigned-byte 16))
 (deftype rod () '(array rune (*)))
 (deftype simple-rod () '(simple-array rune (*)))
 ------------------

 Unicodeを扱うためのものであることは間違いなさそうだ。

 runeは英語の意味(ルーン文字/呪文)そのまんまから来たんだろうな。rod
 は？stringがひもだからそれとの対応としてムチってことかな?

 さて、Unicodeとか、UTF-8とかを正確に理解していないような気がする。
 私の理解ではUnicodeというのは文字集合の定義とエンコーディング達の定
 義を含む総称的な規格であり、その中でもUTF-8というのはPlan9を発祥と
 するエンコーディングというものだった。だけどここではUnicodeに対応し
 ているものはrune、そうでないものはutf-8という分け方がされている。
 むぅ。Unicode 対応ということが何かがわかってないんだな、私は。
 
 文字関係については、確か今夜わかるメールプロトコル、にあったような。
 あった、自分なりの補足や調査も交えつつまとめる。

 ** 文字((graphic) character):

 言葉を表記するために社会習慣として用いられる記号。

 例: アルファベット、数字、ギリシャ文字、漢字、ひらがな、カタカナ。
 
 ** 文字集合(character set):

 文字の集合。膨大な文字を計算機で扱いやすくするために、よく使う文字
 だけを集めていることが多い。下記の例はcodedが入っていることからわか
 るとおり、文字集合の定義だけでなく、次項の文字コードの定義も含んで
 いる。ただし、文字集合が何を指すかというのは規格化団体毎に揺れがあ
 る。

 例:
 ISO/IEC 8859-1:1998
 Information technology - 8-bit single-byte coded graphic character
 sets - Part 1: Latin alphabet No.1

 JIS X 0208
 7ビット及び8ビットの2バイト情報交換用符号化漢字集合

 ** 文字コード

 文字集合に対して、それと数値を対応づける方式。文字符号化方式
 (character encoding scheme)と呼ばれることもある。ただし、文字コード
 が何を指すかというのは規格化団体毎に揺れがある。

 例：
 JIS X 0208は文字集合を規程するとともに、ISO-2022-JP、EUC-JP、
 Shift_JISという3つの文字コードを規程している。

 さて、ではUnicodeは？

 ** UnicodeはUnicode Consortiumが企画の策定・維持を行っている規格で
 ある。

 ** The Unicode Standardという文書で規程している。

 ** The Unicode Standardではそれぞれの文字について、名前とコード
 ポイントを定めている。code pointとは数値のことである。

 ** 現在の最新バージョンは5.1.0である。

 ** バージョン5.0とISO/IEC 10646は互換である。

 ** 5.1.0はWebで公開されている。しかしそのPDFは印刷できない。5.0は
 書籍としても出版されている。

 ** The Unicode Standardは、character encoding standardである。
 これ以降特にことわりがない限り、The Unicode Standard version 5.1.0
 についての話とする。

 ** 3つのエンコーディング形式を定めている。a 32-bit form (UTF-32)、
 a 16-bit form (UTF-16)、 an 8-bit form (UTF-8)。(あれ？ やはり
 UTF-8とUnicodeに対する理解は間違っていなかった)

 ** コードポイントの総数は、1,114,112である。(百万以上)

 ** コードポイントの始めの65,536をBasic Multilingual Plane (BMP)と呼ぶ。

 ** コードポイントは、0から0x10FFFFまでの間の値をとる。

 ** 計算機でテキスト処理をするさいには、そのテキストの要素については
 いろいろな表現形式や取り扱いがあるであろう。ここでは、テキスト要素
 とはコードポイントであるとする。その意味で、コードポイントのことを
 encoded characters(符号化文字)と呼ぶ。

 ** ここまでがだいたいChapter 1 Introduction。

 ** 続いてChapter 2 General Structure。

 ** Chapter 2 のアウトライン。

 *** text representationとtext processingの本性について整理する。

 *** The Unicode Design Prinsipleを紹介する。

 *** the Unicode character encoding model を紹介する。そこでは、
 character、code point、encoding forms という概念がそれらの相関ふく
 めて導入される。これらによって、UTF-8、UTF-16、UTF-32の説明が可能
 となり、これらエンコーディングの利点・欠点もあわせて説明する。

 *** the Unicode codespaceを紹介する。

 *** writing directionの話題を説明する。

 *** equivalent sequencesとnormalizationを説明する。

 *** the Unicode Standardに対するcomformanceについてざっくりと説明す
 る。(お、ここでUnicode対応とはなんぞやがわかるかも)

 ** 2.1 Architectual Context

 character code standardというのはそれ自体が計算機のテキスト処理のア
 プリケーションを成しているわけではなく、有用なアプリケーションをつ
 くるための部品である。部品であるがゆえ、様々な用途に使われる。それ
 ゆえすべての用途のrequirementsをみたしたものを作るのは不可能であり、
 それらをいい感じでみたすようなバランスをとることになる。

 
 *** Basic Text Processes

 たいていの計算機では、low-levelのテキスト処理機能をまず用意して、
 それをもとに多様なテキスト処理が組み立てられる。このlow-levelの部
 分をBasic Text Processesと呼ぶ。

 **** Rendering characters visible
 
 **** Breaking lines while rendering
 
 **** Modifying appearance, such as point size, kerning,
 underlining, slat and weight

 **** Determining units such as "word" and "sentence"

 **** Interacting with users in processes such as selecting and
 highlighting text

 **** Accepting keyboard input and editing stored text through
 insertion and deletion

 **** Comparing text in operations such as in searching or
 determining the sort order of two strings

 **** Analyzing text content in operations such as spell-checking,
 hyphenation, and parsing morphology

 **** Treating text as bulk data for operations such as compressing
 and decompressing, truncating, transmitting, and receiving

 
 *** Text Elements, Characters, and Text Process

 なにがtext elementであるということは、どういうtext processにおいて？
 ということと不可分である。普遍的なというか、text processと独立して
 いるようなtext elementsの定義は存在しない。

 例えば、英語の"A"と"a"はレンダリングでは別のものだが、語を検索する
 ときには同じと扱われる。ドイツ語では、letter combination "ck"は、
 ハイフネーションするときは"k-k"として分離して扱うが、sortするとき
 は"ck"を一体として扱う。

 また、英語でspell-checkするときは、"the quick brown fox,"の"fox"が
 テキスト要素になる。

 で、Unicodeがcharacter encoding standardとして定めているのは、text
 elementsでなく、もっとアトミックなcharacterですよ。それを特定する
 code pointsですよ。それらをassigned characterと呼びますよ。

 charactersからtext elementsを作る形態は4つある。

 **** composite (合成)

 **** Collation Unit (照合単位)

 **** Syllable (音節(を表わすつづり文字))

 **** Word (語)

 *** Text Processes and Encoding

 the Unicode Standardは特定のbasic text-processing algorithmsに依存
 しないように設計している。

 ** 2.2 Unicode Design Principles

 ---
 Universality: The Unicode Standard provides a single, universal
 repertoire.

 Efficincy: Unicode text is simple to parase and process.

 Characters, not glyphs: THe Unicode Standard encodes characters,
 not glyphs.

 Semantics: Characters have well-defined semantics.

 Plain text: Unicode characters represent plain text.

 Logical order: The default for memory representaion is logical
 order.

 Unification: The Unicode Standard unifies duplicate characters
 withiin scripts across languages.

 Dynamic composition: Accented forms can be dynamically composed.

 Stability: Characters, once assigned, cannot be reassigned and key
 properties are immutable.

 Convertibility: Accurate convertibility is guaranteed between the
 Unicode Standard and other widely accepted standards.
 ---

 今、興味があるものだけ深掘りする。

 *** Characters, Not Glyphs

 Characters: 書き言葉の最小単位の抽象表現である。ここで書き言葉は意
 味論上の価値を持つものに限る。代表的なものとして、letters、
 punctuation、signsなどがある。自然言語で使われるlettersをグルーピ
 ングしたものはscriptsと呼ぶ。あるletterが異なるscriptsに属すること
 もあろう。そして、それが意味論的にも見た目的にも同一だとする。それ
 でもUnicodeはそれらを別のcharactersとして扱う。scriptsの分類が優先
 ということ。

 glyphというのは要は見た目のこと。ただし、単一のletterに関するもの
 だけではなく、letterの連続もあることに注意たとえば、英語の筆記体に
 て"fox"と単語で書くときと"f""o""x"と個別に書くときではglyphが違う。

 fontというのは、Rendering processにおけるUnicode charactersから
 glyphsへのマッピングである。

 *** Semantics

 Unicodeのsemanticsは、characterの名前やcode table上の位置などでは
 な定義しない。すなわち暗黙の定義はしない。character propertiesで明
 示的に定義する。それらを格納したものをThe Unicode Character
 Databaseと呼ぶ。このdatabaseの情報をもとに、parsing、sortingなどの
 アルゴリズムを構築する。

 Unicode流のアプリケーションプログラミングをする場合、このdatabase
 のsemanticsを核におくことになり、i18n対応のためのcode set indepent
 modelは不要になる。code set indepent modelでは、byte-streamの
 semanticsはcode set毎に異なるという見地から、byte-streamの取り扱う
 際には、個別のcode setの個別に定義されたsemanticsを選択的に適用する
 機構を有するものである。これがUnicodeでは不要となる。もちろん例えば
 UTF-8を単なるcode setの追加と位置付けて、code set independet model
 で取り扱うことも可能ではあるが。

 *** Unification

 scriptsという概念とlanguagesという概念はUnicodeでは別。そして、先
 程書いたように、同じletterが別のScriptに属するならば、そのletterの
 Semanticsや見た目が同じでも別のcharacterとするが、別のlagnguageで
 使用されるletterであってもそれを同じscriptにまとめらるならば統一し
 て単一のcharacterにしてしまう、ということ。

 ** 2.3 Compatibility characters

 ここは今の興味には無関係なので割愛。

 ** 2.4 Code Points and Characters

 抽象的であるcharactersという概念は、計算機の内部では、具体的に数と
 して表現される。

 その数の値域をcodespaceと呼ぶ。その中のひとつの数をcode pointと呼
 ぶ。

 code pointとencoded characterは一対一対応ではない。例えば、Aの上に
 ○があるabstract character の eEncoded characterは、次の3通りがある。

 code point : 00C5
 code point : 212B
 code point : 0041 + code point : 030A

 最後のものは、letter A のcode pointとletter 上付き○のDynamic
 Compositionである。

 Unicodeのcode pointの表記の関連は、"U+" + 16進数である。

 U+0061  LATIN SMALL LETTER A
 U+201DF CJK UNIFIED IDEOGRAPH-201DF

 *** Types of Code Points

 code pointsはいくつかの観点でカテゴライズできる。

 基本的な分類は次のとおり。

 ---
 Graphic:
 Letter, mark, number, punctuation, symbol, and spaces
 Assigned to abstract character

 Format:
 Invisible but affects neighboring characters; includes
 line/paragraph separators
 Assigned to abstract character

 Control:
 Usage defined by protocols or standards outside the Unicode
 Standard
 Assigned to abstract character

 Private-use:
 Usage defined by private agreement outside the Unicode standard
 Assigned to abstract character

 Surrogate:
 Permanently reserved for UTF-16; restricted interchange
 Not assigned to abstract character

 Noncharacter:
 Permanent reserved for internal usage; restricted interchange
 Not assigned to abstract character

 Reserved:
 Reserved for future assignment; restricted interchange
 Not assigned to abstract character
 ---

 ** 2.5 Encoding Forms

 計算機は数というものを数学上の数そのままとしてではなく、fixed-size
 units で取り扱う。例えばbyteとか32-bit wordsとか。character
 encodingはそういう現実に則して設計する必要がある。

 計算機上で整数は特定のcode unitsとして実装される。ここでcode units
 は、たいていが、8-bit、16-bit、32-bitである。

 そこで、Unicodeのencoding formsでは、それぞれのcode point(整数)を
 どのようにa sequence of code unitsとして表現するかを規程している。

 The Unicode Standardでは、code units 8-bit, 16-bit, 32-bitに対応し
 て、次の3のencoding formsを提供している。

 UTF-8, UTF-16, UTF-32

 UTFは、Unicode (or UCS) Transformation Formatの略である。

 これらはどれも表現力として等価であり、相互変換がロスレスで可能であ
 る。

 *** Non-overlap

 CP932等はoverlapするが、Unicodeはoverlapしない。これは便利。

 どういうことかというと、CP932は1byteまたは2byteで表現するのだが、
 2byteのleading byteと1byteが衝突することはないが、1byteと2byteの
 trailing byteは数として衝突することがある。これは衝突している文字
 (1byte)側を検索するときなどやっかいである。

 The Unicode encoding formsではこの心配はない。lead、trail、single
 だろうがなんだろうが、何かを表現している数にoverlapは存在しない。

 *** Conformance

 "The Unicode Consortium fully endorses the use of any of the three
 Unicode encoding forms as a conformant way of implementing the
 Unicode Standard. It is important not to fall int the trap of
 trying todistinguish "UTF-8 versus Unicode," for example."

 あり？ ということは、cxml-domの記述はおかしくないか？
 やはり私のそもそもの理解でただしかったのか？
 もう少しUnicodeを読みといてから、考える。

 *** Examples.

 AΩ語(不思議な文字)

 UTF-32 00000041    0000003A9    00008A9E    00010384
 UTF-16     0041         03A9        8A9E   D800 DF84
 UTF-8        41        CE A9    E8 AA 9E F0 90 8E 84

 *** UTF-32

 もっともシンプル。code pointの数とcode unitの数が一対一対応。
 値域は0..0x10FFFF。いわずもがなだが、code pointと同じ。
 なので、U+0000..U+10FFFFというcode pointの表記そのままがencodingの
 値である。
 
 
 *** UTF-16

 U+0000..U+FFFF (BMP)は、そのまま16-bit code unitひとつで表わす。
 U+10000..U+10FFFFは、2つの16-bit code unitsであらわす。このペアを
 surrogate pairと呼ぶ。surrogate pairに割り当てる領域は先の単一の
 encodingに使われる領域とは隔離されている。これがnon-overlapを実現し
 ている。


 *** UTF-8

 U+0000..&+007F ASCII code points (0x00..0x7F)

 それ以外は、Table 3-6をみるのがよさげ。

うーん。とりあえず、ここまで。次回は2.6 Encoding Schemes。
なんかUnicodeのお勉強になっているが、ま、気にしない。

こつこつ。

2008年9月16日火曜日

意味論をぼやぼやと

プログラミング言語関係で、わかりにくい言葉に「意味論」がある。私はさっぱりわからない。Semanticsを意味論と訳していることも、誤訳じゃないかと疑っているくらいだ。(意味という言葉にひっぱられて、理解しずらくなっているんじゃないか、という責任転嫁)

Semantic Webとかもさっぱりわからない。単にメタデータがつくことがSemanticなの? とか。OWLでオントロジ書けばSemanticなの?とか。

先々、プログラミング言語のSemanticsもかじるとして、ぼやぼやと準備を初めようと思う。

まずは、計算機科学にくる前の「意味論」ってどんなものなんだろ、という興味にて、

「ルイス・キャロルの意味論」

を読もうと思う。

なんとか、深掘りせずに、お気楽にいきたい。。。

2008年7月19日土曜日

C言語の意味(論)

Cをやってみて感じるのは、意味を考えるとき、メモリとかレジスタとかデータ・パスとか、いわゆるプログラム内蔵式の計算機を考えている自分がいるということですね。意味論というものの価値を私はうたがっており、Cプログラマにおける意味論というのはこの程度で済んでしまってOKなものじゃないかなと思うのです。

まあ、もちろん価値といったとき、誰におけるどのような価値か、ということが重要なのですが。意味論が好き、という人にとってはもちろん意味論の価値は高いのでしょう。私も結構好きですが。

登録: 投稿 (Atom)

計算機とその周辺: What I Talk About When I Talk About Computers

2009年7月26日日曜日

【検証論】5 ホーア論理の数学

2009年7月11日土曜日

【AIMAメモ】論理言語の意味論(Semantics)

2009年7月7日火曜日

【LPN】8 More Definete Clause Grammars

2009年2月5日木曜日

XMLを扱う (その19) [The little XMLer ?]

2009年1月31日土曜日

XMLを扱う (その11) [Common Lisp][Unicode]

2008年9月16日火曜日

意味論をぼやぼやと

2008年7月19日土曜日

C言語の意味(論)

ラベル

自己紹介

ブログアーカイブ

2009年7月26日日曜日

2009年7月11日土曜日

2009年7月7日火曜日

2009年2月5日木曜日

2009年1月31日土曜日

2008年9月16日火曜日

2008年7月19日土曜日

ラベル

自己紹介

ブログ アーカイブ

ブログアーカイブ