アカウント名:
パスワード:
XMLとその関連技術は素晴らしすぎて、20年後の現在もかなり完成されているように見える。今はJSON好きが多いけれど、XMLより劣る点は多い。現在でもつかわれるプロトコルとして、SMTPとかのメール周りは改良点は多数あるし(参考 [srad.jp])、HTMLは実際手を入れられているが再設計するならかなり良くなるだろう。その点でXMLをより良くするなら、今の視点で設計するなら、というのはテーマとして面白いと思う。
自分としては、
こんな所かな。あればいいなと思ったら大抵あるのがXMLのすごい所。
XMLの「閉じタグにタグ名を書く」のは何とかならんもんなんですかね</>で良いんだったらだいぶ心穏やかになるな
名前空間が使いにくいのもちょっと微妙だが機能が高いので仕方ないのかな…
XMLの基となったSGMLでは出来ましたよね、空終了タグ (empty end tag) [kikakurui.com]。と言っても実際に使われてるのは見たことないので、規格上だけの存在だったからXMLではばっさりカットされてしまったのかもしれませんが。
> およそあらゆる言語に変換できるXMLプログラミング言語。
IDLからCORBAとかのスタブつくるみたく、XMLスキーマからスタブ...は今でもそこそこある気はするけど、XMLでプログラム自体を書いて変換、なのかな。
それはもうメタ言語として別にしたほうがたぶんいいと思う...
XSLT なんてまさに XML でプログラム書いてるようなものだが、超めんどくさい。C言語の "=",",","(",")","{","}" などなどに相当するものを全部 element で囲って書くはめになるんだから。XSLT 2.0 以降では、"if ... then ... else ..." を書ける attribute も登場したのは、みんな「めんどくせー」、って思ったせいじゃないかしら。
SGML「」
HTMLは実際のところ、XML化を諦めてる。SGML由来のdtdより柔軟になったとは言え、Schemaを理解してまともに書ける技術者は限られている。指摘にもあるけどnamespaceは素晴らしい仕組みだが、すごく分かりにくいです。交換データ形式としては優れていても、人が直接書くものじゃ無いよ。
現在のHTMLのパーサーはチューリング機械が必要なので設計の美しさなんて宇宙の彼方に放り投げてる
個人的には’/‘1文字のコストをかけてでもXHTMLからの流れで閉じタグは必須にした方が仕様がかなり単純化できて良かったと今でも思ってる。
でも、今のHTML (WHATWG)って、過去作られたHTML文書もすべて処理できることを目指しているっぽいので(WHATWG FAQ 日本語訳 ブラウザーは今後も古い HTML ドキュメントを理解してくれるのでしょうか? [html5.jp])、閉じタグ必須化を仕様に盛り込むのはあり得ない選択肢だったののかなと思います。
UTF-8のみ認める、非UTF-8な過去文書はステ、とか言い出してるんですがそれは
バイナリに対する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))))
# 待てよ、もしかするとこれでプログラムも書けるのでは?
Syntax Error。閉じ括弧が一つ足らないね。
ガクガクブルブル(((( ;゚Д゚))) つ)僕の一個あげるよ
くそっこんなんでw
閉じカッコがたくさん並んで醜いし対応ミスもあるから、']'1つで全部閉じるってのはどうでしょうか?
それ、スーパー括弧閉じにするよりVectorにした方が良くないですか〜ってEDN記法見て思うの〜(a b c ) => list[ a b c ] => Vector(配列){:keywords value} => マップ
clojureの記法だけどこれ良く出来てると思うの。これを元にHTMLもXMLもまとめて扱ってるhiccup記法とかすごいとおもうのだけどなぁ。
#SGML,XML,HTMLのタグ記法ってLispの亜種なんだよね(開始の部分で何を意味するか指定してるけどそれ括弧の直後に書いてもいいじゃんよー)
key valueと要素数二つの配列をどうやって区別すんの?
区別しない
Key Value Pairだけが存在して、配列はKeyが先頭要素でValueに2番目以降の要素が入った再帰的なKVPで代用する
お、何か画期的なプログラミング言語ができるような気がしてきたぞ
> LispのS式じゃね?
S式の劣化コピーですね
配列と言った時点でS式が理解できてないしネタとしてもイマイチ
JSONですから(嘘つけ)
今更のツッコミも野暮だし全部グダグダ
ASN.1の何が不満なんだ
1. 理解できない2. 本が高い3. OSI臭い# もちろんジョークだ
XMLにもそのまま当てはまるような(OSIはW3Cあたりに置き換えるとして)
ASN.1見たことないだろ。もちろん、転送構文も含めて。
それは何のS式ですか?
XMLそのものの改良や再設計と、XSLTやXAMLのようにXMLを使って実現したいものは分けた方がいいような。
およそあらゆる言語に変換できるXMLプログラミング言語
は後者だよね。
Excelファイルでいいじゃん。。。。。。。。。。
客「結局はcsv出力でいきましょう」
客「文字化けCSVなんか送ってくんな!」
Windows Live Mailのアドレス帳は、「CSVでエクスポートしたあと一旦Excelに読み込ませて保存」しないとOutlookで文字化けするとhttps://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=019472 [121ware.com]
そのExcelファイルも、今やXMLが中で使われている時代 (Office Open XML)。
個人的には、Office 2003の独自XML形式が好きだったんだけどなあ。Office 2007以降、ダブルクリックで各Officeアプリで開く関連づけがなくなったのが残念。.doc、.docx、.xls、.xlsxなどメインの形式より低機能な代わりに比較的プログラムで生成しやすく、しかもOfficeアプリに関連づけられていたので、他人にもMS Office形式のファイルと称して渡せるという都合のいいデータ形式だった。
例えるならMicrosoft Officeのようなものか?
HTML高速な(かつ安定した)DOMパーサが実装できるから、その恩恵も大きいと思う。あとXPathを使いこなすと便利。
XPathはかなり便利な良い仕様よね。XPointerは難しすぎたが。。。
「charset が出現するまでは必ず ASCII コード」という規約が欲しいいや、BOM なし UTF-16 な XML なんて存在しないならどうでもいいのですが。
# オレオレパーサを書くのが一番悪いってのはわかっているのですが
いや、それマトモにテキストエディタで開けないから駄目だろ
同じ理由で大きなバイナリを埋め込む仕組みとかの拡張も無理そう。PDFとか基本テキストベースのはずが読める気がしない。
途中で文字コードが変わるテキストデータの話ではなく、文字コードの判別方法に関してです。
BOM つき UTF-16→わかる7bit 領域は ASCII 互換→charset の結果でわかる(SJIS とか UTF-8 とか)BOM なし UTF-16→ビッグエンディアンの UTF-16 と判別して読み込む(が、どう判別する?)
2 番目まで処理してパースに失敗したら 3 番目処理して、というのが現実的な解でしょうか?(これだけのために文字コード判別のライブラリとか組み込みたくないので)
BOMとか見るなら、頭2バイト見ればわかるんじゃないの?
0x3c 0x3f ならASCII互換の「<?」なのでencoding指定まで読み進める0xFE 0xFF ならUTF-16のBig Endian0xFF 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ではない
という判定をすれば事足りるよねっていう?
ここまで網羅しておいて、どうして2バイトと口走ったw4バイトで決定できるで良かったのでは。
XMLパーサはUTF-8とUTF-16が使えるのが最低要件だから、UTF-32とか考えなくていいかなーって思ったけど、惰性で追加しちゃったとか、そういう
つまりただのうっかりです、ぐぬぬ
HTML 5.1ならば、文字コードはutf-8固定になるようですがね〜
> XMLより劣る点は多い。
XMLは必要とされてない機能に無駄にコストを掛けてたってことだよ。
JSONはよく必要とされるものまで足りないけどな。コメントとか、標準化されたパス書式とかスキーマ定義とか(JSONの方が表現できる型が多いのに)。
通信データにはJSONが向いてるけど、データ処理ではXMLが扱い易いシーンも多い。JSONにすりゃいいってもんじゃないのに、何でもJSONじゃなきゃ嫌がる人はちょっと困る。
XMLはXPathとかNodeとか周辺まで仕様で決まってますからねそこまでがXMLなのか、フォーマットだけの話なのか
とはいえ周り全部なければ認めないとかいう事になると実装コストが上がるので、初めからそうだったらJSONは普及しなかったのかもしれないなー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
今再設計するなら…とか? (スコア:1)
XMLとその関連技術は素晴らしすぎて、20年後の現在もかなり完成されているように見える。
今はJSON好きが多いけれど、XMLより劣る点は多い。
現在でもつかわれるプロトコルとして、SMTPとかのメール周りは改良点は多数あるし(参考 [srad.jp])、HTMLは実際手を入れられているが再設計するならかなり良くなるだろう。
その点でXMLをより良くするなら、今の視点で設計するなら、というのはテーマとして面白いと思う。
自分としては、
こんな所かな。
あればいいなと思ったら大抵あるのがXMLのすごい所。
Re:今再設計するなら…とか? (スコア:3)
XMLの「閉じタグにタグ名を書く」のは何とかならんもんなんですかね
</>
で良いんだったらだいぶ心穏やかになるな
名前空間が使いにくいのもちょっと微妙だが機能が高いので仕方ないのかな…
Re: (スコア:0)
XMLの基となったSGMLでは出来ましたよね、空終了タグ (empty end tag) [kikakurui.com]。
と言っても実際に使われてるのは見たことないので、
規格上だけの存在だったから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: (スコア:0)
個人的には’/‘1文字のコストをかけてでもXHTMLからの流れで閉じタグは必須にした方が仕様がかなり単純化できて良かったと今でも思ってる。
Re: (スコア:0)
でも、今のHTML (WHATWG)って、過去作られたHTML文書もすべて処理できることを目指しているっぽいので(WHATWG FAQ 日本語訳 ブラウザーは今後も古い HTML ドキュメントを理解してくれるのでしょうか? [html5.jp])、閉じタグ必須化を仕様に盛り込むのはあり得ない選択肢だったののかなと思います。
Re: (スコア:0)
UTF-8のみ認める、非UTF-8な過去文書はステ、とか言い出してるんですがそれは
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)
閉じカッコがたくさん並んで醜いし対応ミスもあるから、']'1つで全部閉じるってのはどうでしょうか?
Re: (スコア:0)
それ、スーパー括弧閉じにするよりVectorにした方が良くないですか〜ってEDN記法見て思うの〜
(a b c ) => list
[ a b c ] => Vector(配列)
{:keywords value} => マップ
clojureの記法だけどこれ良く出来てると思うの。
これを元にHTMLもXMLもまとめて扱ってるhiccup記法とかすごいとおもうのだけどなぁ。
#SGML,XML,HTMLのタグ記法ってLispの亜種なんだよね(開始の部分で何を意味するか指定してるけどそれ括弧の直後に書いてもいいじゃんよー)
Re: (スコア:0)
key valueと要素数二つの配列をどうやって区別すんの?
Re: (スコア:0)
区別しない
Key Value Pairだけが存在して、配列はKeyが先頭要素でValueに2番目以降の要素が入った再帰的なKVPで代用する
お、何か画期的なプログラミング言語ができるような気がしてきたぞ
Re: (スコア:0)
Re: (スコア:0)
> LispのS式じゃね?
S式の劣化コピーですね
配列と言った時点でS式が理解できてないし
ネタとしてもイマイチ
Re: (スコア:0)
JSONですから(嘘つけ)
Re: (スコア:0)
今更のツッコミも野暮だし全部グダグダ
Re: (スコア:0)
ASN.1の何が不満なんだ
Re: (スコア:0)
1. 理解できない
2. 本が高い
3. OSI臭い
# もちろんジョークだ
Re: (スコア:0)
XMLにもそのまま当てはまるような(OSIはW3Cあたりに置き換えるとして)
Re: (スコア:0)
ASN.1見たことないだろ。もちろん、転送構文も含めて。
Re: (スコア:0)
それは何のS式ですか?
Re:今再設計するなら…とか? (スコア:1)
XMLそのものの改良や再設計と、XSLTやXAMLのようにXMLを使って実現したいものは分けた方がいいような。
およそあらゆる言語に変換できるXMLプログラミング言語
は後者だよね。
うじゃうじゃ
Re:今再設計するなら…とか? (スコア:1, 興味深い)
Excelファイルでいいじゃん。。。。。。。。。。
Re: (スコア:0)
客「結局はcsv出力でいきましょう」
Re: (スコア:0)
客「文字化けCSVなんか送ってくんな!」
Windows Live Mailのアドレス帳は、「CSVでエクスポートしたあと一旦Excelに読み込ませて保存」しないとOutlookで文字化けすると
https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=019472 [121ware.com]
Re: (スコア:0)
そのExcelファイルも、今やXMLが中で使われている時代 (Office Open XML)。
個人的には、Office 2003の独自XML形式が好きだったんだけどなあ。Office 2007以降、ダブルクリックで各Officeアプリで開く関連づけがなくなったのが残念。.doc、.docx、.xls、.xlsxなどメインの形式より低機能な代わりに比較的プログラムで生成しやすく、しかもOfficeアプリに関連づけられていたので、他人にもMS Office形式のファイルと称して渡せるという都合のいいデータ形式だった。
Re: (スコア:0)
例えるならMicrosoft Officeのようなものか?
Re: (スコア:0)
HTML高速な(かつ安定した)DOMパーサが実装できるから、その恩恵も大きいと思う。
あとXPathを使いこなすと便利。
Re: (スコア:0)
XPathはかなり便利な良い仕様よね。
XPointerは難しすぎたが。。。
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: (スコア:0)
ここまで網羅しておいて、どうして2バイトと口走ったw
4バイトで決定できるで良かったのでは。
Re:今再設計するなら…とか? (スコア:1)
XMLパーサはUTF-8とUTF-16が使えるのが最低要件だから、UTF-32とか考えなくていいかなーって思ったけど、惰性で追加しちゃったとか、そういう
つまりただのうっかりです、ぐぬぬ
Re: (スコア:0)
HTML 5.1ならば、文字コードはutf-8固定になるようですがね〜
Re: (スコア:0)
> XMLより劣る点は多い。
XMLは必要とされてない機能に無駄にコストを掛けてたってことだよ。
Re: (スコア:0)
JSONはよく必要とされるものまで足りないけどな。
コメントとか、標準化されたパス書式とかスキーマ定義とか(JSONの方が表現できる型が多いのに)。
通信データにはJSONが向いてるけど、データ処理ではXMLが扱い易いシーンも多い。
JSONにすりゃいいってもんじゃないのに、何でもJSONじゃなきゃ嫌がる人はちょっと困る。
Re:今再設計するなら…とか? (スコア:2)
XMLはXPathとかNodeとか周辺まで仕様で決まってますからね
そこまでがXMLなのか、フォーマットだけの話なのか
とはいえ周り全部なければ認めないとかいう事になると実装コストが上がるので、
初めからそうだったらJSONは普及しなかったのかもしれないなー