2

MGraph は、Microsoft "Oslo" が提供する優れたテキスト データ形式です。

今日の XML と同じくらい広くなる可能性はあると思いますか?

例 (Google ジオコード):

{  
  name = "waltrop, lehmstr 1d",  
  Status {  
    code = 200,  
    request: "geocode"  
  },  
  Placemark [  
    {  
      id = "p1",  
      address = "Lehmstraße, 45731 Waltrop, Deutschland",  
      AddressDetails { Country {CountryNameCode = "DE", CountryName = "Deutschland", AdministrativeArea { AdministrativeAreaName = "Nordrhein-Westfalen", SubAdministrativeArea = { SubAdministrativeAreaName = "Recklinghausen", Locality { LocalityName = "Waltrop", Thoroughfare { ThoroughfareName = "Lehmstraße" }, PostalCode = { PostalCodeNumber = "45731" }}}}}, Accuracy = 6 },  
      ExtendedData {  
        LatLonBox {  
          north = 51.6244226,  
          south = 51.6181274,  
          east = 7.4046111,  
          west = 7.3983159  
        }  
      },  
      Point {  
        coordinates [ 7.4013350, 51.6212620, 0 ]  
      }  
    }  
  ]  
}

モード情報はこちら: Microsoft "Oslo" MGraph - 次の XML?

4

5 に答える 5

1

仕方がないのですが、オスロは、解決すべき本当に優れた具体的な問題を探している解決策だと思っています。彼らがそれを見つけることを心から願っています。

また、今年の PDC を充実させるには何か楽しいことが必要だと感じました。

于 2009-01-12T20:25:17.523 に答える
1

M に関する James Clark の考えに応えて:

また、M と Oslo に欠けているものもありますが、まったく同じではありません。

M がコレクション内のエンティティが保持される順序を保持するという保証があると便利です。ただし、要素をどのように並べるかは、実装の詳細です。M に順序付けされたコレクションがあり、それをデータベースに保持する場合、そこでの順序をどのように維持しますか? 唯一の方法は、データの形状についていくつかの仮定を立て、指定していない列をテーブルに追加することです。その場合、データ構造の形状を完全に制御する方が理にかなっています。

同じことがアイデンティティにも言えます。メモリ内にオブジェクト ID がある理由は、各オブジェクトがメモリ内の異なる場所を割り当て、そのメモリ アドレスを一意に識別するためです。ただし、データベースに保存すると、この情報は関連性がなくなります。そのレコードを一意に識別し、主キーとして機能させるには、列または列の組み合わせが必要です。指定しない場合は、M が列を作成する必要があり、発見するのが難しいある種のトリックを除いて、列への参照はありません。つまり、「固有のアイデンティティ」はありません。それを明示的に識別するデータが常に存在します。

ドキュメントとデータは別のものではありません。XML はドキュメント自体を処理しません。階層データを表すだけであり、ドキュメントはこれから構成されます。データが構造化されている限り、階層のさまざまな部分のクラスを記述し、ある型を別の型から参照してそれらを任意の複雑なツリーに構成できるのと同じ方法で、M で表すことができます。確かに、これは自由形式のテキストであり、XSD スキーマを作成しない限り実際の検証がないため、XML でまとめる方が簡単ですが、その場合、コード クラスで型と関係を定義するのと同じ種類の作業を行うことになります。 .

したがって、最終的に、M は構造を定義したドキュメントを処理し、その構造には実際には何の制限もありません。問題は、それがどれほど簡単かということです。XML 文書を分解して M スキーマを生成するツールに対するあなたの考えは、非常に優れたものです。これを作成することや、Microsoft がツール チェーンをもう少し成熟させれば、ツール チェーンに含めることはそれほど難しくないと思います。「醜くなる」構造に関する限り、データ構造が本当にそれほど複雑である場合、それはそれです。スキーマ化には、XSD、M、または C# クラスと同様に大きな利点がありますが、SQL Server データベース (具体的には Oslo リポジトリ) に格納することが目標である場合は、必要かつ価値があります。

私は、M とそれをサポートするツール チェーンが、驚くほど便利なものに進化すると確信しています。明らかに今、多くのものが欠けています。個人的には、M が現在、開発者がモデリングを開始するのが最も自然に感じられる概念レベル (Entity Framework など) ではなく、リレーショナルな物理データベース レベルでのモデリングを対象としているという事実の方が心配です。結局のところ、MGraph からオブジェクトをインスタンス化するクラスを作成する場合 (DSL の目的と出力)、クラスが永続化される方法とはまったく異なる方法で定義される可能性があります。特にモデルで継承を使用する場合。

標準化については賛成です。それはいいね。ただし、このデータを Oslo リポジトリに保存することが目標であるため、それほど重要ではないと思います。特に、SQL Data Services が十分に成熟してリポジトリをホストできるようになると、このデータをクエリおよび操作するためのさまざまなプロトコルと形式がすべて用意されることになります。クライアントは、JSON、POX、SOAP、MGraph などを使用してメッセージをフォーマットし、ADO.NET Data Services を介してクエリと更新を行うことができます。MGraph データに必要なのは、データベースにデータを取得するための MGraph コネクタだけであり、そこから想像できるあらゆる方法でアクセスできます。

オスロの詳細については、こちらの記事をご覧ください: http://dvanderboom.wordpress.com/2009/01/17/why-oslo-is-important/

于 2009-01-28T15:12:35.533 に答える
0

...そして、JSON ではできないことは何ですか?

于 2009-01-12T20:37:38.420 に答える
0

なぜ MGraph は常に YAML ではなく XML と比較され、はるかに似ているのでしょうか。私たちが定期的に車輪を再発明するのは、無知なのか盲目なのか?

PS:これは、YAML がどのように見えるかです (カスタム データ型と、JSON に加えて YAML が提供するノード 'p1' への参照なし):

{  
  name: "waltrop, lehmstr 1d",  
  Status: {  
    code: 200,  
    request: "geocode"  
  },  
  &p1 Placemark: [  
    {
      address: "Lehmstraße, 45731 Waltrop, Deutschland", 
      ExtendedData: { LatLonBox: {  
          north: 51.6244226,  
          south: 51.6181274,  
          east: 7.4046111,  
          west: 7.3983159
      }},  
      Point: { coordinates: [ 7.4013350, 51.6212620, 0.0 ] }
    }  
  ]  
}
于 2010-08-04T21:19:56.820 に答える