XML誕生から20年 37
ストーリー 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:今再設計するなら…とか？ (スコア:2, おもしろおかしい)
バイナリに対する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:今再設計するなら…とか？ (スコア:1)
((key0 value0)
(key1 (value10 value11 value 12))
(key2 ((key20 value20)
(key21 (value210 value211 value222))))
Syntax Error。閉じ括弧が一つ足らないね。
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プログラミング言語。
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そのものの改良や再設計と、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: (スコア:0)
> XMLより劣る点は多い。
XMLは必要とされてない機能に無駄にコストを掛けてたってことだよ。
仕様が自由過ぎて悩ましい (スコア:1)
書き方1
書き方2
どっちが正しいのか分からず、数名と議論して、結局「書き方2」の方を選びましたけども。
ちなみにoptionは有る場合と無い場合があります。
# 細かい部分は省略
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: (スコア:0)
私なら次のように考えますね。
option の内容は複雑か（階層化した方が良いか）
→YES なら書き方 2
→No なら、option の数は 0..1 か 0..* か
→0..1 なら書き方 1
→0..* なら書き方 2
初期値ないし単一のバインディングで済む書き方 1 で済むなら、そちらの方が楽です。
ただし、それで表現できないケースは書き方 2 にせざるを得ません。
まぁチーム開発で混乱したり議論になったり、後で書き方 1 → 2 になって面倒だ、ってなるぐらいなら 2 に統一で良いと思いますよ。
Re: (スコア:0)
XMLの設計における
「構造のもつ意味を正確に記述するよう強いたい」という欲求と
「機械的になんでも書ける、扱えるようにしたい」という欲求のせめぎあいの果てに、
今の末端ユーザの混乱があるように思う。
S式があったのに (スコア:0)
みんなそんなに Lisp が嫌いなの
Re: (スコア:0)
Lispが嫌いとかじゃなくより広く普及させるために費やした労力の差の気がします
Re: (スコア:0)
それだけコストを掛けてもあっさりJSONに追い抜かれた
この役立たず者 (スコア:0)
でいいんじゃないか
XMLっていつ最初に利用しました？ (スコア:0)
RSSの配信がXMLだったから利用したかな？
そのあとはJavaプログラムでかな。
それでもiniファイル (スコア:0)
今でもiniファイルに固執してる人がいるから困る
客のロートルがiniファイルじゃないと変更できないって言うから仕方ないけど、未だにXMLを知らない・学ぶ意欲も無い人に重要な設定を弄らせるのはどうなんだろうかと思わなくもない
Re: (スコア:0)
人を馬鹿にして自分が優位だと思いたい人？
Re: (スコア:0)
ファイルを編集する以外の方法で設定できるようにすれば何の問題もないな。お前がサボってるだけだ。
jsonパーサとxmlパーサの両方ともCで実装した経験がありますが (スコア:0)
XMLの設計した奴は糞だな、というのが率直な感想でした