アカウント名:
パスワード:
書き方1
<sample> <item option="abc"> <name>ABC</name> </item></sample>
書き方2
<sample> <item> <name>ABC</name> <option>abc</option> </item></sample>
どっちが正しいのか分からず、数名と議論して、結局「書き方2」の方を選びましたけども。ちなみにoptionは有る場合と無い場合があります。# 細かい部分は省略
私なら次のように考えますね。
option の内容は複雑か（階層化した方が良いか）→YES なら書き方 2→No なら、option の数は 0..1 か 0..* か →0..1 なら書き方 1 →0..* なら書き方 2
初期値ないし単一のバインディングで済む書き方 1 で済むなら、そちらの方が楽です。ただし、それで表現できないケースは書き方 2 にせざるを得ません。
まぁチーム開発で混乱したり議論になったり、後で書き方 1 → 2 になって面倒だ、ってなるぐらいなら 2 に統一で良いと思いますよ。
大体同意。自分はぶっちゃけ、属性で済むデータ構造なら数がいくらあろうと属性で完結させてしまう。属性で表現できない構造を要素に展開していく。まあノードの意味も低優先で考慮はするけど。
#3360237は、
<sample> <item name="ABC" option="abc" /></sample>
こうしたい。
ついでに長い文字列になる可能性があるなら2にしない？改行とか"とか含まれることが想定される場合も2の方が見やすいと思う。
現場レベルだとそういう判断は要るんだけど、理想を言うとテキストエディタの編集都合のためにXMLのフォーマットを変えるのは本道じゃ無いんだよなと思う。本当はスタンダードなXMLエディタというものが存在して、そのツール上では属性値も改行や引用符がそのまま使えるという姿であるべきだった。テキストエディタでXMLを編集するのは、ある意味テキストをバイナリエディタで編集するのと同じ行為で、メタ情報までいじれてしまうのはあんま良い形ではない。
まあ結局、今日に至るまで支持されるXMLエディタは生まれていないのが現実なのだけれど。
どんな用途を想定してるかによるけど、大抵の場合、どっちも間違ってる気がする。
普通に考えるなら「item要素はnameの値に紐付いている」ように見えるから、
<sample> <item name="ABC"> <option>abc</option> </item></sample>
になるのが筋じゃないのかなーって？
itemという要素の中にnameという要素を内包しているのか、itemという要素が持つ属性の1つがnameなのか。どっちを意図したデータなのかでしょー？
追記。
特定の要素を、いわゆる表形式のデータベースと対比して考えたときに、１レコードに該当する要素があるなら、そのレコードのキー値は「要素の子要素ではなく、属性として実装されるべき」だと思います。
だって「特定のキーを元に要素を取り出したい」ときに、わざわざ子要素を見てから「その親要素を取得する」って処理として変じゃないの？っていう話。
dtd、Schemaとパーサー次第。妥当性検査するならきっちり決めた方がいいし、そうではなく連想配列に単純に突っ込みたいならどっちでもいい。Attributeはあくまで属性なので、読み飛ばされてもデータの根幹部分を毀損しないような感じにしてるけど、そうで無いschemaも見るのでそれぞれかな。
Attributeという名前に惑わされてないか。ElementもText NodeもAttributeも、等しくNodeの派生であって、XMLの規格で優先順位や重要度は設定されていない。故に、（事前に明確に不要とわかっている時以外は）読み飛ばすような処理をしてはならないし、一般的なXMLパーサーにそんな挙動はない。
XPath の string 関数で element node を文字列化すると、直下や配下 element node 配下の text node は文字列中に含まれるけど、配下 attribute node 配下の text node は文字列中に含まれない、とかはあるよね。XPath の仕様が変なわけでもなく、XMLノードを文字列化する際によく見る仕様だと思う。（HTMLの仕様がそうだから、XML非対応ブラウザで無理やり XML を開いた場合等もそんな感じになる）
規格上、element も attribute も等しく node であるというのはそうだけれども、だったら element だけあればよいのであって、attribute なんていらない。
少なくとも、XPath の規格設計者はそう考えてるんだと思う。
XPath使うならchildのtext見るより対象ノードのattributeみる方が自然だと思うけど。特定の要素が不可分に持つデータは属性、分離しても意味を持ちうるのが子要素じゃないの？
XMLの設計における「構造のもつ意味を正確に記述するよう強いたい」という欲求と「機械的になんでも書ける、扱えるようにしたい」という欲求のせめぎあいの果てに、今の末端ユーザの混乱があるように思う。
nameとoptionの意味次第かな？消えても良いなら属性保持するなら要素
属性はファイルで言うとパーミッション/ACLに該当（互換性無い環境に移動すれば失われる）
消えても良いなら属性保持するなら要素
こういう誤解（だと思う）をちらほら見かけるけど、どこから来るんだろ。
XML勧告では「属性が検証できなければ（≒互換性のない環境に移動したら？）CDATAとして扱わなければならない（SHOULD）」ことになってるので、消えても良いなんてことはない筈。少なくとも「消してる」処理系はあっても、「消えてもよい」というスタンスでどうにかしてるのは見たことない。
や、それ以前に、XMLの要素を「移動する」という概念がそもそも不明瞭なのだけど（DOMでいうDocumentFragmentみたいなやつ？）たとえば、何かしらのプログラミング言語とかで、XMLの要素（Element）を引数に渡したときに、それを言語側の処理系（ランタイムやライブラリ等）が理解できなくて「ないものとして扱う」のなら、それはXMLの処理系としては不完全な実装でしかなくて、XMLの一般的な扱い方じゃないと思うんだけどなー。
>XMLの処理系としては不完全な実装その通りですよ。まあ相手側の処理で要素しか見てくれないのが実際有ったので期待しない形ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
仕様が自由過ぎて悩ましい (スコア: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: (スコア:0)
大体同意。
自分はぶっちゃけ、属性で済むデータ構造なら数がいくらあろうと属性で完結させてしまう。
属性で表現できない構造を要素に展開していく。まあノードの意味も低優先で考慮はするけど。
#3360237は、
<sample>
<item
name="ABC"
option="abc"
/>
</sample>
こうしたい。
Re: (スコア:0)
ついでに長い文字列になる可能性があるなら2にしない？
改行とか"とか含まれることが想定される場合も2の方が見やすいと思う。
Re: (スコア:0)
現場レベルだとそういう判断は要るんだけど、
理想を言うとテキストエディタの編集都合のためにXMLのフォーマットを変えるのは本道じゃ無いんだよなと思う。
本当はスタンダードなXMLエディタというものが存在して、そのツール上では属性値も改行や引用符がそのまま使えるという姿であるべきだった。
テキストエディタでXMLを編集するのは、ある意味テキストをバイナリエディタで編集するのと同じ行為で、
メタ情報までいじれてしまうのはあんま良い形ではない。
まあ結局、今日に至るまで支持されるXMLエディタは生まれていないのが現実なのだけれど。
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)
XPath の string 関数で element node を文字列化すると、
直下や配下 element node 配下の text node は文字列中に含まれるけど、
配下 attribute node 配下の text node は文字列中に含まれない、
とかはあるよね。
XPath の仕様が変なわけでもなく、XMLノードを文字列化する際によく見る仕様だと思う。
（HTMLの仕様がそうだから、XML非対応ブラウザで無理やり XML を開いた場合等もそんな感じになる）
規格上、element も attribute も等しく node であるというのはそうだけれども、
だったら element だけあればよいのであって、attribute なんていらない。
Re: (スコア:0)
少なくとも、XPath の規格設計者はそう考えてるんだと思う。
XPath使うならchildのtext見るより対象ノードのattributeみる方が自然だと思うけど。
特定の要素が不可分に持つデータは属性、分離しても意味を持ちうるのが子要素じゃないの？
Re: (スコア:0)
XMLの設計における
「構造のもつ意味を正確に記述するよう強いたい」という欲求と
「機械的になんでも書ける、扱えるようにしたい」という欲求のせめぎあいの果てに、
今の末端ユーザの混乱があるように思う。
Re: (スコア:0)
nameとoptionの意味次第かな？
消えても良いなら属性
保持するなら要素
属性はファイルで言うとパーミッション/ACLに該当（互換性無い環境に移動すれば失われる）
Re:仕様が自由過ぎて悩ましい (スコア:1)
こういう誤解（だと思う）をちらほら見かけるけど、どこから来るんだろ。
XML勧告では「属性が検証できなければ（≒互換性のない環境に移動したら？）CDATAとして扱わなければならない（SHOULD）」ことになってるので、消えても良いなんてことはない筈。少なくとも「消してる」処理系はあっても、「消えてもよい」というスタンスでどうにかしてるのは見たことない。
や、それ以前に、XMLの要素を「移動する」という概念がそもそも不明瞭なのだけど（DOMでいうDocumentFragmentみたいなやつ？）
たとえば、何かしらのプログラミング言語とかで、XMLの要素（Element）を引数に渡したときに、それを言語側の処理系（ランタイムやライブラリ等）が理解できなくて「ないものとして扱う」のなら、それはXMLの処理系としては不完全な実装でしかなくて、XMLの一般的な扱い方じゃないと思うんだけどなー。
Re: (スコア:0)
>XMLの処理系としては不完全な実装
その通りですよ。
まあ相手側の処理で要素しか見てくれないのが実際有ったので期待しない形ですね。