日本語

開発者ツール · 構文コンバーター

XML の SGML からの系統: 属性、名前空間、DTD がある理由

· 背景

XML データ形式 セキュリティ

XML 属性、名前空間プレフィックス、および拒否された DOCTYPE の横の混合テキスト
オリジナル ToolAcre ベクトル イラスト

XML の奇妙な点 (属性と要素、名前空間、DTD、混合コンテンツ) は、それがデータ用ではなくドキュメント用の簡略化された SGML として設計されたことを知れば理解できます。この投稿では、その系譜と、XML を JSON に変換する場合の意味を追跡します。

このデータ形式に属性があるのはなぜですか? — 開発者が XML を JSON に変換し、JSON という区別を満たす必要はありませんでした

JSON には 1 種類のオブジェクト プロパティがあります。 XML は、属性、子要素、テキストを区別します。 ToolAcre は、その区別を `@` 属性と通常の子キーでマップします。違いは、要素に `id="7"` と `<id>` の子の両方がある場合に顕著です。両方とも別のプロパティの下で存続します。

この規則は、属性が 1 つの普遍的な意味論的な役割を持つとは主張せずに、結果として得られる形状を説明します。 XML 作成者は、独自のスキーマに基づいてそれらを選択します。コンバーターは、選択されたビジネス上の理由ではなく、観察できるノード カテゴリを保持します。

SGML とドキュメントの伝統 — ISO 8879、公開用のマークアップ、およびレコードをエンコードするのではなくテキストにタグを付けるという考え方

混合コンテンツ、順序付けされた子、属性、コメント、および処理命令は、XML ソースに存在するドキュメント指向の機能です。この実装では、その処理を示していますが、SGML 年表、ISO 発行履歴、出版業界の動機に関する証拠は含まれていません。

したがって、ソース限定アーティクルは実行可能動作から始まります。子要素の周囲のテキストには損失が含まれます。コメントと処理命令は削除されます。 CDATA はマークされたままになります。これらの事実は、ドキュメント ツリーが JSON 値ツリーにきれいに適合しない理由を説明しています。

ドキュメント指向の XML 機能が実装で表示されます (SGML 履歴要求なし)

パーサーは、整形式の XML を検証し、行と列を報告します。結果の値の宣言は無視され、5 つの組み込みエンティティと数値文字参照がデコードされたテキストとして保存されます。ワーキンググループの目標や 10 原則の設計説明を確立するものではありません。

歴史的主張には外部編集ソースが必要ですが、このタスクでは追加されません。依存関係名からコンプライアンスや来歴を考え出すよりも、それらを省略する方が正確です。

パーサーは XML 構文を処理します。リポジトリの証拠は 1998 設計履歴を確立していません

属性は、`@` という接頭辞が付けられたキーになります。要素はその名前を保持します。構造化要素内のテキストは `#text` に移動しますが、テキストのみの要素は文字列に折りたたまれます。これにより、オブジェクト モデルが許す限り、構造的なカテゴリが分離されます。

XML を記述すると、規則が逆になり、`@id` が属性になります。無効な属性名または要素名はサニタイズされずに拒否されます。この決定により、不正なマッピングが、暗黙的に名前が変更されたもっともらしい XML になることがなくなります。

属性と要素は、ToolAcre の @ 規則に従って区別されます。

名前空間接頭辞は、名前空間宣言を含む要素名と属性名でそのまま保持されます。これらは解決、削除、または書き換えられません。これはソースのスペルを保持しますが、名前空間を意識した型解決ではありません。

fast-xml-parser がドキュメントを受信する前に、すべての DOCTYPE が拒否されます。マスクは、コメントと CDATA 内の誤った一致を回避します。これにより、拒否を回避するオプションがなく、外部エンティティの要求、ローカル ファイル エンティティの読み取り、およびエンティティ拡張攻撃が防止されます。

名前空間プレフィックスは文字通り保持され、すべての DOCTYPE は拒否されます

`<p>before<b>bold</b>after</p>` では、テキストの配置が重要です。 ToolAcre は混合コンテンツを検出し、`#text` の下でフラグメントを結合し、子に対する相対的な位置が失われることを警告します。 JSON オブジェクト プロパティは、テキスト ノードと要素ノードが交互に並ぶ順序付けされたシーケンスを再現できません。

繰り返される同じ名前の子は配列になりますが、異なる名前の兄弟はプロパティのままです。正確なドキュメント順序を必要とするコードでは、変換されたオブジェクトを完全なものとして扱うのではなく、XML ノード表現を使用する必要があります。

これでカバーされないもの — XSLT、XPath、および XQuery、XML を中心に発展した処理言語

XSLT、XPath、および XQuery はインポートまたは公開されません。また、パネルは XSD を検証したり、DTD 宣言を処理したり、型指定されたドメイン オブジェクトを構築したりしません。これは、明示的なセキュリティと忠実度の境界を持つデータ投影です。

クエリ言語または変換言語は、このプレーン値変換ではできない方法でノードの順序を保持および移動できます。ドキュメントの機能が付随的なパッケージ化ではなく作業の一部である場合には、そのツールを選択してください。

要点: XML はデータを運ぶことを学習したドキュメント形式であり、JSON への変換後に何が残っているかが構文コンバーター パネルにどのように表示されるか

XML の監視可能なデータ モデルには、JSON にはない区別が含まれています。 ToolAcre は属性、CDATA、構造化テキストをマークし、名前空間プレフィックスを保持し、非データ ノードを削除し、DOCTYPE を拒否します。それぞれの選択肢が表示され、テストされます。

このパネルを使用して、歴史的権威や完全な XML プロセッサとしてではなく、投影後に生き残るものを学びます。順序付けするときは、スキーマまたは名前空間のセマンティクスが重要であり、元のツリーを保持し、専用の XML ツールを使用します。

セキュリティと忠実性は DOCTYPE 境界でも交差します。宣言を拒否するとエンティティの処理ができなくなりますが、任意のレガシー ドキュメントから宣言を削除すると、エンティティの参照や検証の前提が変更される可能性があります。ソースを所有している場合は、必要なエンティティを明示的な安全なテキストに置き換えて、結果のドキュメントを検証します。所有していない場合は、拒否を弱めたり、部分的な変換を元のコンテンツとして提示したりするのではなく、承認された XML ワークフローを使用してください。