2

Web 上で xml タグの長さの制限についての言及を見つけることができませんでした。サード パーティがデータを送信するための仕様として機能する XML スキーマを構築しようとしています。

スキーマ (およびデータ) は、階層的でユーザーがカスタマイズ可能なカスタム オントロジー/データ ディクショナリのものに準拠することになっています。

自然なマッピングは、階層内のノードを使用して、XSD/XML 内のタイプとタグに名前を付けるためのものです。ただし、オントロジーのリーフ ノード名は一意である必要はないため、階層内のノードのフル パスをタグ名としてエンコードし、XML 字句規則に合わせて適切にマングルすることを検討しています。

したがって、私のオントロジーに複数の「リサ」ノードがあり、それらが階層内の異なる場所にあるため、異なるものを意味する場合、ノードへのフル パスを使用して、異なる XML タイプ/タグ名を生成できます。

 <abe_homer_lisa> simpsons lisa ... </abe_homer_lisa>
 <applei_appleii_lisa> ... apple lisa </applei_appleii_lisa>
 <mona_lisa> and paintings </mona_lisa>

... あいまいさのない、同じファイル内のさまざまな「lisa」タイプのデータ。

タグの最大長 (または標準準拠のエンジンでサポートされているタグの最小長) を指定している Web 上の情報が見つかりません。(XML の字句規則の概要はこちら)

属性の長さについても同じことが尋ねられました。標準で属性の制限が指定されていない場合、タグの制限があるとは思えませんが、実際には制限がある可能性があります。

実際の制限でさえ、私のニーズよりもはるかに大きいと思います (ほとんどの場合、255 文字よりも小さいと予想されます)。基本的に、Java XML プロセッサ、標準の ETL ツール、および一般的な XSLT プロセッサがすべて、これよりもはるかに大きなタグを処理できる場合、問題にはなりません。

4

6 に答える 6

7

たとえば1K文字の名前を処理できないツールを見つける可能性は低いと思います。その時点で、厳しい制限ではなく、深刻なパフォーマンスとユーザビリティの問題に直面しています。

しかし、あなたのデザインは間違っています。XMLは階層的であり、それと戦うのではなく、事実を利用します。

于 2013-01-11T14:06:43.553 に答える
4

私が知っているタグ名の長さに制限はありませんが、XML 仕様に制限が記載されていなくても、XML を解析しようとするツールによっては実装上の制限が生じる場合があります。

一方、XML のネイティブで本質的な階層構造を使用しない理由はありません。次のようにエンコードするのではなく、すべてを <abe_homer_lisa> としてエンコードする理由:

<abe>
    <homer>
        <lisa>simpsons lisa</lisa>
    </homer>
</abe>
<applei>
    <appleii>
        <lisa> ... apple lisa </lisa>
    </applei>
</appleii>
于 2013-01-11T11:07:25.670 に答える
3

確立された XML メカニズムを使用して要素を区別すること、つまり名前空間を使用することを強くお勧めします。そうすれば、例えば

<lisa xmlns="http://example.com/simpsons">..</lisa>

<lisa xmlns="http://example.com/apple">...</lisa>

W3C スキーマ言語と XSLT および XPath の両方が名前空間を完全にサポートしています。

于 2013-01-11T11:16:05.720 に答える
0

上記のMichaelKay（XMLの専門家）とMihai Stancuのコメントに基づいて、私の最初の質問に対する答えは次のとおりでした。

  • 公式の制限はありません
  • 絶対最小値として1000文字以上をサポートする可能性が高いツール
  • パフォーマンスの問題が発生する可能性があります[これらのファイルを処理するXMLツールでは、非常に長い文字列に対して多くの文字列のインデックス作成と比較を行う必要があります]。
  • XML名前空間および/またはドキュメントツリーの構造を使用して識別コンテキストを提供することは、タグ名を「一意化」するためのより良い方法である可能性があります

私は合法的なタグの長さに関する非常に具体的な質問に答えた後、同じ質問が属性の長さについて尋ねられたがタグについては尋ねられなかったので、誰かがグーグルで検索した場合に備えて「答え」を付ける価値があると思いました。すべての回答者に感謝します。私のデザインが賢明であったかどうかについての有効なポイント。理論的根拠は他の場所で説明します。

于 2013-01-14T14:10:59.797 に答える
0

根底にある問題に対処するためのより賢明な方法があるかもしれないと指摘してくれた人々に感謝します (XML スキーマ内の型/タグ名が一意であることを保証します)。

コンテキストを提供するためにノードの階層を使用する場合: これは一般的に適切であることに同意します。ただし (q では正確な問題領域については詳しく説明しませんでした)、この特定のケースでは、対処しなければならないツリー構造のデータ ディクショナリ内のユーザー構成可能な項目のグループ化はかなり恣意的であり、ほとんど関係がありません。ディクショナリが記述するデータ内の関係。

だから、

 <abe>
   <homer>
     <lisa>lisa1</lisa>
   </homer>
 </abe>

たとえば、別のリサ ノードは同じホーマー ノードの下にあるべきですか、それとも別のノードの下にあるべきですか? 本塁打者は同じ阿部ノードの下にあるべきかどうか? 問題のデータの場合、区別は多かれ少なかれ無意味です。特定の本でたまたま参照された索引のページに従ってデータをグループ化するようなものです。任意の呼び出しを行い、XSD でロックダウンできると思います。

XSL のようなものを使用してデータを抽出する場合は問題ありません。//abe/homer/lisa は、それらがどのようにグループ化されたかに関係なく、すべての lisa ノードを取得します。実際には、誰かが CSV ファイルなどからこれらを生成する可能性が高いので、できるだけフラットな構造を好むでしょう。

名前空間についても同様です: それらはまさにこの目的のために設計されていますが (名前のコンテキストを提供し、異なるタイプのデータがファイルにまとめられているときに偶発的な衝突があいまいさを引き起こさないようにします)、実際には追加のレイヤーを追加しますソースシステムからデータを生成する人にとっての複雑さ。

私の正確な状況では、この恣意的なグループ化で名前が衝突する可能性はほとんどない (そして不適切な使用法を反映している) と予想されるため、過半数のケースに過度のペナルティを課すことなく、合理的な処理が必要です。

于 2013-01-14T15:00:10.033 に答える
-1

従来の知識に反して、いわゆるXML名前空間メカニズムを使用しないことを強くお勧めします。長い間、それはあなたに痛みを引き起こします。名前空間にノーと言ってください。あなたはそれらを必要としません。

要素をコンテキスト（この場合は「パス」で表す）で区別できるというあなたの直感は正しいです。ただし、パス全体を要素の名前にエンコードするという考えは最適ではない場合があります。代わりに、コンテキストまたはパスを保持する属性とともに、単純な名前を使用することを検討してください。（この属性に「コンテキスト」または「パス」またはより刺激的な名前を付けてください！）これは、意味を区別するのに十分です。[*]

さまざまなコンテンツモデルの場合、同じ手法の変形を使用できます。それぞれの異なるタイプに状況に応じて便利な名前を付け、「オントロジー」などの名前の別の属性に「実際の」名前を記録します。

あなたの質問に関しては、XML仕様では名前の長さに固有の制限はありませんが、純粋に技術的な理由から、一部の場所で引用される65536文字の制限が見つかる場合があります。同じ「制限」が、属性値リテラルの長さにも適用される場合があります。アトミック名ごとに平均20文字の場合でも、20レベルの階層はパスに対して500バイト未満になるため、心配する必要はほとんどありません。

[*]注：この手法は実際には非常に古いものですが、XMLマインドスペースではほとんど完全に忘れられています。たとえば、HTMLには、あらゆる種類のGUIコントロールをカバーするために名前が付けられた単一の要素タイプがありますが、' '属性INPUTのおかげで混乱はありません。type

于 2013-01-11T14:07:46.963 に答える