您对 Microsoft Oslo MGraph 感觉如何？

Question

MGraph是微软“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？

Answer 1

我想知道为什么 MGraph 总是与 XML 进行比较，而不是与看起来更相似的 YAML 进行比较。 我们经常重新发明轮子是无知还是盲目？

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 ] }
    }  
  ]  
}

Answer 2

以下是 James Clark 的部分想法on M：

“我发现 M 中缺少几个主要的东西，这些东西的缺失对于 M 的数据库应用程序来说可能是可以接受的，但这对于 M 的其他应用程序来说将是一个重大障碍。最基本的是顺序M 有两种类型的复合值，集合和实体，它们都是无序的，无序是无序的，但属性不能有结构化值，但在 XML 中没有办法。例如，子元素的顺序并不重要。对于许多应用程序来说，缺乏对无序数据的支持显然是 XML 的弱点。另一方面，顺序对于其他应用程序来说同样重要。显然，您可以伪造顺序。 M 通过在实体中拥有索引字段等来实现，但它仍然是假的。一个好的建模语言需要以一流的方式支持有序和无序数据。 这个问题可能是最基本的，因为它影响数据模型。

M 似乎薄弱的另一个领域是身份。 在抽象数据模型中，实体具有独立于其字段值的身份。 但类型系统迫使我通过创建复制实体固有身份的人工字段，以类似 SQL 的方式谈论身份。 更糟糕的是，身份的范围是范围，它是平面表。 与此相关的是对层次结构的支持。 图是比树更通用的数据模型，因此我很高兴拥有图而不是树。 但是当我处理树时，我希望能够说该图是一棵树（这相当于指定对图中节点身份的约束），并且我希望能够将其作为树进行操作，特别是我想要分层路径。

XML 的优点之一是它可以处理文档和数据。 这很重要，因为世界并没有整齐地划分为文档和数据。 您拥有包含文档的数据和包含数据的文档。 干净地建模文档所需的关键是混合文本。 您将如何支持 M 中的文档？ 缺乏对顺序的支持是这里的一个主要问题，因为有序是文档的规范。

一个相关的问题是 M 和 XML 如何结合在一起。 我相信有一种规范的方法可以将 M 值表示为 XML 文档。 但是如果您有 XML 格式的数据，您如何用 M 来表达它呢？ 在许多情况下，您需要将 XML 结构转换为可以清晰地对数据建模的 M 结构。 但您可能并不总是愿意花时间这样做，并且如果您的 XML 具有类似文档的内容，它会变得很难看。 您最好将 XML 块表示为 M 中的简单值（就像在 JSON 世界中一样，您经常会得到包含 HTML 块的字符串）。 M 应该让这变得容易。 您可以使用 RELAX NG 优雅地解决这个问题（我知道鉴于 Microsoft 对 XSD 的承诺，这不会发生，但这是一个有趣的思想实验）：提供一个函数，允许您约束一个简单的值来匹配所表达的 RELAX NG 模式使用紧凑语法（可能会调整紧凑语法以与 M 的其余语法协调一致）并使用 M 的简单类型库作为 RELAX NG 数据类型库。

最后，还有标准化问题。 在我看来，XML 的成就主要不是技术上的成就。 这是一种社会性的：让大量社区同意使用一种通用格式。 标准化是达成这一协议的关键因素。 XML 不会作为单一供应商格式出现在任何地方。 令人震惊的是，PDC 上关于奥斯陆的讨论多次提到了开源，以及微软如何将规范置于其开放规范承诺之下，以实现开源实现，但没有提及标准化。 我可以理解这一点：如果我是微软，我当然不会热衷于重复XSD或OOXML的经历。 但开源并不能替代标准化。

"

请阅读此处 James Clark 关于Oslo 建模语言的博客文章。

Answer 3

我情不自禁，但我有点觉得奥斯陆是一个寻找真正优秀的具体问题来解决的解决方案。 我真心希望他们能找到它。

我还觉得他们需要一些有趣的东西来充实今年的 PDC。

Answer 4

回应 James Clark 对 M 的看法：

我也看到 M 和 Oslo 缺少一些东西，但又不完全相同。

如果能够保证 M 能够保留集合中实体的保留顺序，那就太好了。 但是，如何对元素进行排序是一个实现细节。 如果 M 中有一个有序集合，并且将其保存到数据库中，那么如何维护它们的顺序呢？ 唯一的方法是对数据的形状做出一些假设，向您未指定的表添加一些列，在这种情况下，完全控制数据结构的形状更有意义。

身份也是如此。 我们在内存中拥有对象标识的原因是因为每个对象在内存中分配不同的位置，并具有该内存地址来唯一标识它。 然而，当保存到数据库时，此信息不再相关，并且您需要某些列或列组合来唯一标识该记录，以作为其主键。 如果您没有指定它，那么 M 必须为您发明一个列，并且您将无法引用它，除非通过某种可能难以发现的技巧。 换句话说，不存在“固有的身份”； 总有一些数据可以明确识别它。

文档和数据不是两个不同的东西。 XML 本身不处理文档； 它只是代表分层数据，文档就是由它组成的。 只要数据是结构化的，就可以用 M 表示，就像您可以为层次结构的各个部分编写类并从另一种类型引用一种类型以将它们组成任意复杂的树一样。 诚然，这在 XML 中更容易组合在一起，因为它是自由格式的文本，并且除非您编写 XSD 架构，否则没有真正的验证，但在这些情况下，您所做的工作与在代码类中定义类型和关系相同。 。

因此，最终，M 处理您为其定义结构的文档，并且该结构实际​​上没有任何限制。 问题是这样做有多容易。 您对于一个工具来分解 XML 文档并生成 M 模式的想法是一个非常好的想法。 我想编写一个工具并不会太困难，或者一旦它成熟一点，微软将其纳入他们的工具链中。 就结构“变得丑陋”而言，如果您的数据结构真的那么复杂，那就是这样。 对其进行图表化具有很大的优势，在 XSD 或 M 或 C# 类中也是如此，但如果您的目标是将其存储在 SQL Server 数据库（或特别是 Oslo 存储库）中，那么它是必要且值得的。

我非常有信心 M 和支持工具链将发展成为非常令人惊奇和有用的东西。 现在显然还缺少很多东西。 就我个人而言，我更关心这样一个事实：M 目前的目标是在关系、物理数据库级别而不是概念级别（如实体框架）进行建模，开发人员在概念级别开始建模感觉最自然。 毕竟，当编写类来实例化 MGraph 中的对象（DSL 的目的和输出）时，类的定义可能与它们的持久化方式完全不同。 特别是当您在模型中使用继承时。

我同意你关于标准化的观点。 那样就好了。 然而，我认为它不太重要，因为目标是将这些数据存储在奥斯陆存储库中。 特别是一旦 SQL 数据服务足够成熟以托管存储库，我们将拥有所有不同的协议和格式来查询和操作此数据。 客户端将能够通过 ADO.NET 数据服务进行查询和更新，使用 JSON、POX、SOAP、MGraph 等格式化消息。 所有 MGraph 数据都需要一个 MGraph 连接器来将其获取到数据库中，并可以通过任何可以想象的方式对其进行访问。

您可以在我的文章中找到有关奥斯陆的更多信息：
http://dvanderboom.wordpress.com/2009/01 /17/为什么奥斯陆很重要/

Answer 5

...它能做什么而 JSON 不能做什么？