XML誕生から20年 104
ストーリー by headless
生誕 部門より
生誕 部門より
maia 曰く、
2月10日はXML 1.0のリリースから20年だそうだ(XML.comの記事)。
XMLはあまりに基本的な技術となっているが、メタ言語でもあり、何を語るべきかよく分からない。JSONと二題噺にしたら面白いかもしれない。
XML 1.0がリリースされたのは1998年2月10日。Jon Bosak氏が最初のXML Working Groupを結成したのはその1年半前だという。XML Working Groupのオリジナルメンバーで、XML.comの記事を執筆したTim Bray氏によれば、XMLはそれまでできなかった多くのことを可能にし、多くの興味深い仕事やソフトウェアを生み出したとのことだ。
今再設計するなら…とか？ (スコア:1)
XMLとその関連技術は素晴らしすぎて、20年後の現在もかなり完成されているように見える。
今はJSON好きが多いけれど、XMLより劣る点は多い。
現在でもつかわれるプロトコルとして、SMTPとかのメール周りは改良点は多数あるし(参考 [srad.jp])、HTMLは実際手を入れられているが再設計するならかなり良くなるだろう。
その点でXMLをより良くするなら、今の視点で設計するなら、というのはテーマとして面白いと思う。
自分としては、
こんな所かな。
あればいいなと思ったら大抵あるのがXMLのすごい所。
Re:今再設計するなら…とか？ (スコア:3)
XMLの「閉じタグにタグ名を書く」のは何とかならんもんなんですかね
</>
で良いんだったらだいぶ心穏やかになるな
名前空間が使いにくいのもちょっと微妙だが機能が高いので仕方ないのかな…
Re:今再設計するなら…とか？ (スコア:1)
> およそあらゆる言語に変換できるXMLプログラミング言語。
IDLからCORBAとかのスタブつくるみたく、XMLスキーマからスタブ...は今でもそこそこある気はするけど、XMLでプログラム自体を書いて変換、なのかな。
それはもうメタ言語として別にしたほうがたぶんいいと思う...
M-FalconSky (暑いか寒い)
Re: (スコア:0)
XSLT なんてまさに XML でプログラム書いてるようなものだが、超めんどくさい。C言語の "=",",","(",")","{","}" などなどに相当するものを全部 element で囲って書くはめになるんだから。XSLT 2.0 以降では、"if ... then ... else ..." を書ける attribute も登場したのは、みんな「めんどくせー」、って思ったせいじゃないかしら。
Re:今再設計するなら…とか？ (スコア:1)
SGML「」
HTMLは実際のところ、XML化を諦めてる。
SGML由来のdtdより柔軟になったとは言え、Schemaを理解してまともに書ける技術者は限られている。指摘にもあるけどnamespaceは素晴らしい仕組みだが、すごく分かりにくいです。
交換データ形式としては優れていても、人が直接書くものじゃ無いよ。
Re: (スコア:0)
現在のHTMLのパーサーはチューリング機械が必要なので設計の美しさなんて宇宙の彼方に放り投げてる
Re:今再設計するなら…とか？ (スコア:1, おもしろおかしい)
バイナリに対するXMLとして、EBMLというのもあります。
ところで、JSONにもXMLのようなnamespaceなどを扱えるJSON-LDというものがあります。それを見ていると、JSONのようなファイルフォーマットが担うような機能は限定して、必要に応じてJSON-LDのような拡張を行うのが良いような気もします。実際、JSON-LDが必要なケースはJSON全体の利用ケースに比べて限定的ですから。
私はJSONの機能は更に削減できるとさえ考えます。例えば、配列だけで十分なんじゃないかと。例えば、
((key0 value0)
(key1 (value10 value11 value 12))
(key2 ((key20 value20)
(key21 (value210 value211 value222))))
# 待てよ、もしかするとこれでプログラムも書けるのでは？
Re:今再設計するなら…とか？ (スコア:3, おもしろおかしい)
((key0 value0)
(key1 (value10 value11 value 12))
(key2 ((key20 value20)
(key21 (value210 value211 value222))))
Syntax Error。閉じ括弧が一つ足らないね。
Re:今再設計するなら…とか？ (スコア:3, おもしろおかしい)
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ(((( ；ﾟДﾟ))) つ)
僕の一個あげるよ
Re:今再設計するなら…とか？ (スコア:1)
くそっこんなんでw
Re: (スコア:0)
key valueと要素数二つの配列をどうやって区別すんの？
Re: (スコア:0)
区別しない
Key Value Pairだけが存在して、配列はKeyが先頭要素でValueに2番目以降の要素が入った再帰的なKVPで代用する
お、何か画期的なプログラミング言語ができるような気がしてきたぞ
Re: (スコア:0)
Re: (スコア:0)
ASN.1の何が不満なんだ
Re: (スコア:0)
1. 理解できない
2. 本が高い
3. OSI臭い
# もちろんジョークだ
Re: (スコア:0)
XMLにもそのまま当てはまるような(OSIはW3Cあたりに置き換えるとして)
Re:今再設計するなら…とか？ (スコア:1)
XMLそのものの改良や再設計と、XSLTやXAMLのようにXMLを使って実現したいものは分けた方がいいような。
およそあらゆる言語に変換できるXMLプログラミング言語
は後者だよね。
うじゃうじゃ
Re:今再設計するなら…とか？ (スコア:1, 興味深い)
Excelファイルでいいじゃん。。。。。。。。。。
Re: (スコア:0)
例えるならMicrosoft Officeのようなものか？
Re: (スコア:0)
HTML高速な（かつ安定した）DOMパーサが実装できるから、その恩恵も大きいと思う。
あとXPathを使いこなすと便利。
Re: (スコア:0)
「charset が出現するまでは必ず ASCII コード」という規約が欲しい
いや、BOM なし UTF-16 な XML なんて存在しないならどうでもいいのですが。
# オレオレパーサを書くのが一番悪いってのはわかっているのですが
Re: (スコア:0)
いや、それマトモにテキストエディタで開けないから駄目だろ
Re: (スコア:0)
同じ理由で大きなバイナリを埋め込む仕組みとかの拡張も無理そう。
PDFとか基本テキストベースのはずが読める気がしない。
Re: (スコア:0)
途中で文字コードが変わるテキストデータの話ではなく、文字コードの判別方法に関してです。
BOM つき UTF-16→わかる
7bit 領域は ASCII 互換→charset の結果でわかる（SJIS とか UTF-8 とか）
BOM なし UTF-16→ビッグエンディアンの UTF-16 と判別して読み込む（が、どう判別する？）
2 番目まで処理してパースに失敗したら 3 番目処理して、というのが現実的な解でしょうか？
（これだけのために文字コード判別のライブラリとか組み込みたくないので）
Re:今再設計するなら…とか？ (スコア:1)
BOMとか見るなら、頭2バイト見ればわかるんじゃないの？
0x3c 0x3f ならASCII互換の「<?」なのでencoding指定まで読み進める
0xFE 0xFF ならUTF-16のBig Endian
0xFF 0xFE ならUTF-16またはUTF-32のLIttle Endian（UTF-16とUTF-32の確定ができないので4byte目まで読む必要がある）
0x00 0x00 ならUTF-32のBig Endianの可能性が高い（4byte目まで見ないとBOMか確定はできない）
0xEF 0xBB BOMありUTF-8（厳密には3byte目の0xBFまでがBOMだけど）
0x00 0x3c ならUTF-16のBE（BOMなし）
0x3c 0x00 ならUTF-16またはUTF-32のLE
それ以外ならXMLではない
という判定をすれば事足りるよねっていう？
Re:今再設計するなら…とか？ (スコア:1)
XMLパーサはUTF-8とUTF-16が使えるのが最低要件だから、UTF-32とか考えなくていいかなーって思ったけど、惰性で追加しちゃったとか、そういう
つまりただのうっかりです、ぐぬぬ
Re: (スコア:0)
> XMLより劣る点は多い。
XMLは必要とされてない機能に無駄にコストを掛けてたってことだよ。
Re:今再設計するなら…とか？ (スコア:2)
XMLはXPathとかNodeとか周辺まで仕様で決まってますからね
そこまでがXMLなのか、フォーマットだけの話なのか
とはいえ周り全部なければ認めないとかいう事になると実装コストが上がるので、
初めからそうだったらJSONは普及しなかったのかもしれないなー
仕様が自由過ぎて悩ましい (スコア:1)
書き方1
書き方2
どっちが正しいのか分からず、数名と議論して、結局「書き方2」の方を選びましたけども。
ちなみにoptionは有る場合と無い場合があります。
# 細かい部分は省略
Re:仕様が自由過ぎて悩ましい (スコア:2)
Re:仕様が自由過ぎて悩ましい (スコア:1)
私なら次のように考えますね。
option の内容は複雑か（階層化した方が良いか）
→YES なら書き方 2
→No なら、option の数は 0..1 か 0..* か
→0..1 なら書き方 1
→0..* なら書き方 2
初期値ないし単一のバインディングで済む書き方 1 で済むなら、そちらの方が楽です。
ただし、それで表現できないケースは書き方 2 にせざるを得ません。
まぁチーム開発で混乱したり議論になったり、後で書き方 1 → 2 になって面倒だ、ってなるぐらいなら 2 に統一で良いと思いますよ。
Re:仕様が自由過ぎて悩ましい (スコア:1)
どんな用途を想定してるかによるけど、大抵の場合、どっちも間違ってる気がする。
普通に考えるなら「item要素はnameの値に紐付いている」ように見えるから、
<sample>
<item name="ABC">
<option>abc</option>
</item>
</sample>
になるのが筋じゃないのかなーって？
itemという要素の中にnameという要素を内包しているのか、itemという要素が持つ属性の1つがnameなのか。
どっちを意図したデータなのかでしょー？
Re:仕様が自由過ぎて悩ましい (スコア:1)
追記。
特定の要素を、いわゆる表形式のデータベースと対比して考えたときに、１レコードに該当する要素があるなら、そのレコードのキー値は「要素の子要素ではなく、属性として実装されるべき」だと思います。
だって「特定のキーを元に要素を取り出したい」ときに、わざわざ子要素を見てから「その親要素を取得する」って処理として変じゃないの？っていう話。
Re:仕様が自由過ぎて悩ましい (スコア:1)
dtd、Schemaとパーサー次第。
妥当性検査するならきっちり決めた方がいいし、そうではなく連想配列に単純に突っ込みたいならどっちでもいい。
Attributeはあくまで属性なので、読み飛ばされてもデータの根幹部分を毀損しないような感じにしてるけど、そうで無いschemaも見るのでそれぞれかな。
Re:仕様が自由過ぎて悩ましい (スコア:1)
Attributeという名前に惑わされてないか。
ElementもText NodeもAttributeも、等しくNodeの派生であって、XMLの規格で優先順位や重要度は設定されていない。
故に、（事前に明確に不要とわかっている時以外は）読み飛ばすような処理をしてはならないし、一般的なXMLパーサーにそんな挙動はない。
Re: (スコア:0)
XMLの設計における
「構造のもつ意味を正確に記述するよう強いたい」という欲求と
「機械的になんでも書ける、扱えるようにしたい」という欲求のせめぎあいの果てに、
今の末端ユーザの混乱があるように思う。
Re:仕様が自由過ぎて悩ましい (スコア:1)
こういう誤解（だと思う）をちらほら見かけるけど、どこから来るんだろ。
XML勧告では「属性が検証できなければ（≒互換性のない環境に移動したら？）CDATAとして扱わなければならない（SHOULD）」ことになってるので、消えても良いなんてことはない筈。少なくとも「消してる」処理系はあっても、「消えてもよい」というスタンスでどうにかしてるのは見たことない。
や、それ以前に、XMLの要素を「移動する」という概念がそもそも不明瞭なのだけど（DOMでいうDocumentFragmentみたいなやつ？）
たとえば、何かしらのプログラミング言語とかで、XMLの要素（Element）を引数に渡したときに、それを言語側の処理系（ランタイムやライブラリ等）が理解できなくて「ないものとして扱う」のなら、それはXMLの処理系としては不完全な実装でしかなくて、XMLの一般的な扱い方じゃないと思うんだけどなー。
S式があったのに (スコア:0)
みんなそんなに Lisp が嫌いなの
Re: (スコア:0)
Lispが嫌いとかじゃなくより広く普及させるために費やした労力の差の気がします
Re: (スコア:0)
それだけコストを掛けてもあっさりJSONに追い抜かれた
Re:S式があったのに (スコア:1)
＞最後にまとめて
MacLisp系だけどInterLispからもいいとこどりしたという
電総研の研究者が実装したとある処理系は1文字
]
でそれを済ませてくれてpretty printすれば
よきにはからってくれていると事後に確認できる優れものだったので
当時はそういう抵抗はあまりなかった。
この役立たず者 (スコア:0)
でいいんじゃないか
XMLっていつ最初に利用しました？ (スコア:0)
RSSの配信がXMLだったから利用したかな？
そのあとはJavaプログラムでかな。
それでもiniファイル (スコア:0)
今でもiniファイルに固執してる人がいるから困る
客のロートルがiniファイルじゃないと変更できないって言うから仕方ないけど、未だにXMLを知らない・学ぶ意欲も無い人に重要な設定を弄らせるのはどうなんだろうかと思わなくもない
Re: (スコア:0)
人を馬鹿にして自分が優位だと思いたい人？
Re: (スコア:0)
ファイルを編集する以外の方法で設定できるようにすれば何の問題もないな。お前がサボってるだけだ。
Re:jsonパーサとxmlパーサの両方ともCで実装した経験がありますが (スコア:2)
SGML→HTML→XMLだからな？
歴史的事情、当時の状況などを考えると、充分に立派だった。
そもそも、パーサーの実装難度はSGML比で簡単であることが目標であり、誰でも簡単に実装できることは要件ではなかった。
Re:jsonパーサとxmlパーサの両方ともCで実装した経験がありますが (スコア:1)
XMLの方だけでしたが、コメントと階層化への対応が異様に面倒でした。
結局、パーサとして一気に全てを処理するのではなく、ライブラリとして提供して、
一階層ごとにプログラムに制御を返すようにしました。
属性の処理も含めて、その方が柔軟に対処できましたので。
Re:jsonパーサとxmlパーサの両方ともCで実装した経験がありますが (スコア:1)
それSAXと言わない？
Re:jsonパーサとxmlパーサの両方ともCで実装した経験がありますが (スコア:1)
ライセンス問題、クリーンルームも追加で。