2009-07-06 22 views
0

私は、データ交換の目的でXML形式の有限深度グラフと考えることができる表現について考えています。問題点は、エッジタグ内のノードを参照する方法です。私が見る2つの戦略は、a)一意の識別子の使用、またはb)経路の使用です。XML要素階層参照

ユニークなIDが:

<graph id="g0"> 
    <node id="n0"/> 
    <node id="n1"/> 
    <edge from="n1" to="n0"/> 
</graph> 
<graph id="g1"> 
    <node id="n2"/> 
</graph> 
<edge from="n2" to="n1"/> 

パス:

<graph id="0"> 
    <node id="0"/> 
    <node id="1"/> 
    <node id="2"/> 
    <edge from="1" to="0"/> 
    <edge from="2" to="1"/> 
</graph> 
<graph id="1"> 
    <node id="0"/> 
</graph> 
<edge from="1:0" to="0:2"/> 

物事のこれらの種類の標準的な手順は何ですか?私が集めたことから、ユニークな識別子のアプローチがより普及しているようです。グラフが非常に大きくなってきていたときにそれと私の問題があり、そこには:ファイル/ XMLファイルへ

  • からエッジを書き込み/読み込みの目的のためにそのIDにオブジェクトをマッピングし、本当に大きなハッシュテーブルの

    • 必要がエッジがグラフの内部にある場合、冗長パスコンポーネントを省略できないため、パスを使用して記述されたものよりも大きくなります。

    思考?

    アップデート1

    注そのないつの平坦なグラフこと。その1つまたは複数のグラフが相互接続されている。それらはそれぞれ局所的に索引付けされた要素を持っていますが、それらをすべて平坦化し、それらの両端のエッジを追跡することは厄介です。

    アップデート1.1: はGraphMLサブグラフで、彼らは実際にはグローバルなもののうち、ローカルノードIDを分離することが可能となり、複雑なキーを使用しないことに気づきました。

    アップデート2

    はい、明らかにこれはうまく形成XMLおよび行方不明タグとスキーマ宣言のすべての種類ではありません。

  • +1

    参考までに、すべてのxmlのルートノードが必要です。あなたが投稿したものは整形式ではありません。 –

    答えて

    3

    は、このようなグラフを記述するスキーマがある:参照GraphML

    例:

    <?xml version="1.0" encoding="UTF-8"?> 
    <graphml xmlns="http://graphml.graphdrawing.org/xmlns" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns 
        http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"> 
        <graph id="G" edgedefault="undirected"> 
        <node id="n0"/> 
        <node id="n1"/> 
        <node id="n2"/> 
        <node id="n3"/> 
        <node id="n4"/> 
        <node id="n5"/> 
        <node id="n6"/> 
        <node id="n7"/> 
        <node id="n8"/> 
        <node id="n9"/> 
        <node id="n10"/> 
        <edge source="n0" target="n2"/> 
        <edge source="n1" target="n2"/> 
        <edge source="n2" target="n3"/> 
        <edge source="n3" target="n5"/> 
        <edge source="n3" target="n4"/> 
        <edge source="n4" target="n6"/> 
        <edge source="n6" target="n5"/> 
        <edge source="n5" target="n7"/> 
        <edge source="n6" target="n8"/> 
        <edge source="n8" target="n7"/> 
        <edge source="n8" target="n9"/> 
        <edge source="n8" target="n10"/> 
        </graph> 
    </graphml> 
    
    0

    ファイル自体がエッジである場合は、冗長パス構成要素を省略することができないので、パスを使用して書かれたものよりも大きいですグラフの内部。

    この点は早すぎる最適化です。 XMLパーサー/ライターは大きなファイルを詰まらせることはなく、ストレージサイズが問題になる場合、XMLは通常ZIPで非常によく圧縮されます。実装上の問題だ/ XMLファイルへ

    からエッジを書き込み/読み込みの目的のためにそのIDにオブジェクトをマッピングし、本当に大きなハッシュテーブルの

    必要。別の構造でマッピングを維持しようとするのではなく、XML読み書きルーチンをグラフ、ノード、およびエッジクラス自体に書き込むと、このような大きなハッシュテーブルを避けることができます。グラフは、シリアライズとデシリアライズが非常に簡単です。

    おそらくユニークなIDがあります。提案した階層的な方法と同様の方法でIDを構造化すると、XMLの目的の1つである比較的人間が読めるようになります。

    関連する問題