3

私は、Web サイトのコンテンツに次の XML 構造を使用しているクライアントのために働いています。

<section title="title1" layoutType="VideoViewer" xmlPath="xml/ita/title1.xml" pageTitle="extended title" previewImg=""/>

<section title="another title" layoutType="TimeLine" xmlPath="xml/ita/timeline.xml" textFile="" pageTitle="extended title for timeline"></section>

私は XML にはまったく慣れていませんが、これはうまくいきません。タグを閉じるさまざまな方法 ( で自動クローズする/>か、 で明示的にクローズする</section>) は別として、XML はもっと似ているはずだと思っていたでしょう。

<section> 
  <title>title1</title> 
  <layoutType>"VideoViewer" </layoutType>
  <xmlPath>xml/ita/title1.xml </xmlPath> 
  <pageTitle>extended title</pageTitle> 
  <previewImg/>
</section>

<section>
 ...etc etc..
</section>

どう思いますか?

どちらも問題ない場合、「ベストプラクティス」はありますか?

4

8 に答える 8

6

すべての要素が 1 つのルート要素で囲まれている限り、実際には何も問題はありません。

どちらのスタイルの終了タグも使用できますが、内部に他のタグを持たないすべての要素には自己終了タグを使用することをお勧めします。

構造 (タグと属性) に関しては、それは意見の問題であり、どちらのオプションも定義上優れているわけではありません。

于 2009-11-20T15:10:33.273 に答える
3

どちらも正しいです。それは個人的な好みの問題です。

私は自分の見解にいくつかの言葉を費やします。

XMLを教えられたとき、単純なプロパティを格納する必要がある場合は、子要素よりも属性の方が望ましいことを学びました。簡単に言うと、単一非構造化プロパティを意味します。

非構造化部分は単純です。属性は文字列として表すことができます。シングルの場合、プロパティに複数の値を割り当てることはできませんが、同じ子要素を繰り返して、親ノード内にセット/コレクションを作成することはできます。

もっと明確にしたいと思いますが、私はこのテーマについての私の考えをよりよく説明するために英語にそれほど堪能ではありません。

于 2009-11-20T15:25:23.773 に答える
3

なぜ XML はもっとそのようにすべきだと思いますか? 最初のものは属性中心です。あなたが提案しているのは要素中心です。今日では、要素中心のアプローチがより一般的に使用されるようになりましたが、属性中心のアプローチに間違いはなく、いくつかのことをより明確にすることができます。

XML に名前空間がある限り、問題はありません。

于 2009-11-20T15:10:42.503 に答える
2

そのサンプルXMLでの属性の使用に問題はありません。属性には、要素にはないいくつかの制限と、いくつかの重要な利点があります。

まず、制限事項:

  • 属性には単純なコンテンツのみを含めることができます。
  • 属性名は、要素内で一意である必要があります。
  • 定義上、属性の順序はXMLでは重要ではありません。DOMに依存して、特定の順序で属性を反復処理または保存することはできません。
  • node() | @*属性はノードではありません。つまり、XPath( XSLT ID変換で使用されるパターンなど)およびDOM(.NETなど)で属性にアクセスする方法には、属性がない場合でもXmlAttribute派生するいくつかの偏心があります。XmlNodeノードであり、オブジェクトのリストであっても派生XmlAttributeCollection しません。これには十分な理由がありますが、初めて使用する場合はかなり混乱します)。XmlNodeListXmlNode

重要な利点:

  • 属性名は要素内で一意である必要があり、単純なコンテンツのみを含めることができるため、属性値を設定および取得するDOMメソッドは、要素内で値を設定および取得するDOMメソッドよりもはるかに簡単に使用できます。
  • 属性の順序は重要ではないため、属性を作成して使用するコードが属性の順序に関係する必要はありません。
  • 属性には単純なコンテンツしか含まれない可能性があるため、属性のスキーマ定義を作成する方が簡単です。
  • 属性のマークアップは、要素のマークアップよりも簡潔です。

属性はマップ/辞書に非常にきれいに同形化します。名前を有効なXML名に制限し、値をテキストに制限しても問題がない限り、名前と値のペアで構成されるデータ構造の永続的な形式として属性を使用できます。データ構造を構築する場合は、属性を使用できます。入力する順序は関係ありません。

(これは大きな問題を引き起こす可能性があります。WPFでは、XAMLの属性を使用して、設定時に副作用のあるオブジェクトプロパティの値を格納できます。これを行うと、設定Bindingしたからといって、診断が非常に困難なバグが発生します。設定する前のXAMLは、XAMLが表すオブジェクトを構築するときにXAMLが実行SelectedItemすることを意味するわけではなく、まだ設定されていないオブジェクトXamlReaderに設定しようとすると、例外がスローされます。 XAMLを一日中見ることができ、なぜそれが起こっているのかわかりません。)SelectedItemBinding

コードでは、属性を使用する利点は自明です。DOM(C#)fooを使用して要素の属性の値を設定および取得するには:XmlDocument

elm.SetAttribute("foo", value);

value = elm.GetAttribute("foo");

foo 要素の要素の値を設定および取得するには、次のようにします。

XmlElement fooElm = (XmlElement)elm.SelectSingleNode("foo");
if (fooElm == null)
{
   elm.OwnerDocument.CreateElement("foo");
   elm.AppendChild(fooElm);
}
fooElm.InnerText = value;

XmlElement fooElm = (XmlElement)elm.SelectSingleNode("foo");
value = fooElm != null ?? fooElm.InnerText : "";

上記を行うには確かにより効率的な方法があります(ヘルパーメソッドを作成する、XDocument代わりに使用するXmlDocument、またはDOMを完全に回避してシリアル化を使用する)が、要素を操作するのは本質的に複雑です。

あなたの例では、属性を使用してもおそらく問題ありません。順序が重要でない単純な名前/値ペアのマッピングを表しているように見えます。例外はタイトルかもしれません。それらにマークアップを含めることが望ましい場合は、悲しみに陥ります。

編集:

実際、XamlReaderはXAMLに表示される順序で属性を処理すると思います。したがって、XAMLでBinding以前に設定した場合、XAMLの実際のテキストから読み取ってSelectedItemいる限り、例外は発生しない可能性があります。XamlReaderリスクは、XMLドキュメントを読み書きするツールが、XAMLドキュメントの属性の順序を変更することです。KaXamlは、編集するXAMLドキュメントの属性の順序を保持しますか?する必要はありませ

とにかく、XAMLのソリューションは単純です:これを行う代わりに:

<ListBox Binding="{...}" SelectedItem="..." ... />

これを行う:

<ListBox>
   <ListBox.Binding>...</ListBox.Binding>
   <ListBox.SelectedItem>...</ListBox.SelectedItem>
   ...
于 2009-11-20T19:14:49.843 に答える
1

あなたの方法は、私の意見ではより良いです。xml 属性 (title="blah" など) は、その特定のタグの属性を定義するために使用されますが、より複雑なデータ構造に入ると、タグの属性が実際には追加の属性を定義するだけのオブジェクトの観点から考える必要があります。データ (dataTypes、formats など)。

サンプルは正しい方向に向かっていますが、データをどのようにモデル化するかがすべてです。

たとえば、「タイプ」のようなものは、セクションの適切な属性かもしれません (あなたのモデリングを正確に知らずに知ることは困難です) が、私は次のようなものが適切であると仮定します

于 2009-11-20T15:13:48.737 に答える
1

あなたが XML の初心者であることを公然と認めるように、私はW3 Schoolsの方向性を示します。あなたの質問に関しては、正しい答えも間違った答えもありません。どちらももっともらしいです。それはあなた自身の特定の好みにかかっています。

于 2009-11-20T15:15:31.387 に答える
1

XML の方言を設計する私の個人的なスタイルには、属性と要素の両方を組み合わせて、要素に重点を置いています。私の一般的な経験則は、どの要素も 1 行あたり 80 文字 (先頭の空白を除く) を超えてはならず、快適に読むために行の折り返しを必要としないことです。

私は簡単な項目に属性を使用します。これらの項目は、それらが関連付けられている要素に非常に固有であり、複数の値に拡張される可能性はありません。ブール値、数値、および列挙値の属性を作成する傾向があります。たとえば、画像参照要素の場合、幅、高さ、および形式の属性を作成します。

私は、より長い値 (特に、任意の長さになる可能性があるもの)、特に後でより複雑な構造に拡張される可能性があるものに要素を使用します。たとえば、画像参照要素の場合、タイトル、キャプション、説明、URL、およびその他の潜在的に長い自由テキスト値を画像参照要素の子要素にします。

XML は人間が簡単に読み取れるようにする必要があります。XML ダイアレクトは堅牢であり、変更されたときにシステムを壊してはなりません。疑わしい場合は、要素を使用してください。

于 2009-11-20T16:19:50.543 に答える
1

自動終了タグは素晴らしいですが、すべての属性を使用することが「ベスト プラクティス」と見なされるとは思いません。属性には、要素よりも多くの制限があります。

w3schoolsより:

いつ属性を使用し、いつ要素を使用するかについての規則はありません。属性は HTML で便利です。XML では、それらを避けることをお勧めします。代わりに要素を使用してください。

...

属性を使用する際の問題のいくつかは次のとおりです。

* 属性に複数の値を含めることはできません (要素に含めることはできます)
* 属性にツリー構造を含めることはできません (要素に含めることはできます)
* 属性は簡単に拡張できません (将来の変更のために)

属性は読み取りと保守が困難です. データには要素を使用します。データに関連しない情報には属性を使用します。

要素を使用します。

于 2009-11-20T15:41:32.633 に答える