MGraph是微软“奥斯陆”带来的一种出色的文本数据格式。
你认为它有机会像今天这样广泛吗？
示例（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 ]
}
}
]
}
答案 0 :(得分：3)
以下是James Clark's thoughts on M 的一部分：
“我看到M中缺少几个主要的东西，M的数据库应用程序可能无法接受，但这对M的其他应用程序来说是一个重大障碍。最基本的是顺序.M有两种类型的复合值，集合和实体，它们都是无序的。在XML中，无序是有序的不良关系。属性是无序的，但属性不能有结构化的值。元素有结构但是在实例中没有办法说出子的顺序对于许多应用程序而言，缺乏对无序数据的支持显然是XML的弱点。另一方面，顺序对于其他应用程序同样至关重要。显然，您可以通过在实体中包含索引字段来伪造M中的顺序。但是它仍然在假装它。一个好的建模语言需要以一流的方式支持有序和无序数据。这个问题可能是最基本的，因为它会影响数据模型。
M似乎很弱的另一个领域是身份。在抽象数据模型中，实体具有独立于其字段值的标识。但类型系统迫使我通过创建复制实体固有身份的人工字段以类似SQL的方式谈论身份。更糟糕的是，标识的范围是范围，它们是平面表。与此相关的是对层次结构的支持。图是比树更通用的数据模型，所以我很高兴有图而不是树。但是当我处理树时，我希望能够说图是一棵树（相当于指定图中节点标识的约束），我希望能够以树的形式对它进行操作，特别是我想要分层路径。
XML的优势之一是它可以处理文档和数据。这很重要，因为世界并没有整齐划分为文件和数据。您的数据包含包含数据的文档和文档。干净地为文档建模所需的关键是混合文本。你打算如何支持M中的文件？缺乏对订单的支持是一个主要问题，因为有序是文件的标准。
相关问题是M和XML如何结合在一起。我相信有一种规范的方法可以将M值表示为XML文档。但是，如果你有XML格式的数据，你如何在M中表达它？在许多情况下，您需要将XML结构转换为M结构，以便对数据进行清晰建模。但是你可能并不总是想花时间去做那件事，如果你的XML有类似文档的内容，那就会变得很难看。您最好将M的块表示为M中的简单值（就像在JSON世界中一样，您经常会获得包含大块HTML的字符串）。 M应该让这很容易。您可以使用RELAX NG优雅地解决这个问题（我知道这不会发生，因为微软承诺使用XSD，但这是一个有趣的思想实验）：提供一个函数，允许您约束一个简单的值来匹配表达的RELAX NG模式在紧凑语法中（可能会调整紧凑语法以与M语法的其余部分协调）并使用M的简单类型作为RELAX NG数据类型库。
最后，还有标准化问题。在我看来，XML的实现主要不是技术性的。这是一个社交问题：让大量社区同意使用通用格式。标准化是达成协议的关键因素。 XML不会作为单一供应商格式出现。令人吃惊的是，关于PDC的奥斯陆谈判提到了几个开源，以及微软如何将规范置于其开放规范承诺之下以便实现开源实现，但没有提到标准化。我能理解这一点：如果我是微软，我当然不会热衷于重复XSD或OOXML体验。但是开源并不能代替标准化。
“
阅读here James Clark关于Oslo Modelling language的博客文章。
答案 1 :(得分：1)
我无能为力，但我觉得奥斯陆是一个解决方案，寻找一个非常优秀的具体问题需要解决。我真的希望他们能找到它。
我也有这种感觉，他们需要一些有趣的事情来填补今年的PDC。
答案 2 :(得分：1)
回应詹姆斯·克拉克对M的看法：
我也看到M和奥斯陆都缺少一些东西，但不完全相同。
有一些保证M会保留集合中实体的保留顺序，这将是一件好事。但是，您希望如何订购元素是一个实现细节。如果您在M中有一个有序集合并且将其保留到数据库中，那么如何在那里维护它们的顺序？唯一的方法是对数据的形状做一些假设，将一些列添加到您未指定的表中，在这种情况下，完全控制数据结构的形状更有意义。 / p>
同样适用于身份。我们在内存中具有对象标识的原因是因为每个对象在内存中分配不同的位置，并且具有唯一标识它的内存地址。但是，当保存到数据库时，此信息不再相关，并且您需要一些列或列的组合来唯一标识该记录，以作为其主键。如果你没有指定它，那么M必须为你创建一个列，你不会有它的引用，除非可能通过某种可能难以发现的技巧。换句话说，没有“固有的身份”;总有一些数据明确标识出来。
文件和数据不是两回事。 XML本身不处理文档;它只代表分层数据，文档由此组成。只要数据是结构化的，它就可以用M表示，就像你可以为层次结构的各个部分编写类，并从另一个类型引用一个类型以将它们组合成任意复杂的树一样。不可否认，这更容易拼凑在XML中，因为它是自由格式文本，除非您编写XSD架构，否则没有真正的验证，但在这些情况下，您正在执行与在代码类中定义类型和关系相同的工作
因此，最终，M处理您为其定义结构的文档，并且该结构实际上没有任何限制。问题是这样做有多容易。你有一个工具来分离XML文档并生成M模式的想法是一个非常好的想法。我想，一旦它成熟一点，写一个或微软就不会太难以包含他们的工具链。就“丑陋”的结构而言，如果你的数据结构真的那么复杂，它就是它的本质。对它进行模式化具有很大的优势，在XSD或M或C＃类中也是如此，但如果您的目标是将其存储在SQL Server数据库（或特定的Oslo存储库）中，那么这是必要且值得的。
我非常有信心M和支持工具链将演变成非常神奇和有用的东西。现在显然有很多缺失。就个人而言，我更关心的是M目前的目标是在关系，物理数据库级别而不是概念级别（如实体框架）进行建模，这对开发人员开始建模最为自然。毕竟，当编写类来实例化来自MGraphs的对象（DSL的目的和输出）时，您的类的定义可能与它们的持久化方式完全不同。特别是如果你在模型中使用继承。
我同意你的标准化。那样就好了。但是，由于目标是将这些数据存储在Oslo存储库中，因此我认为它不太重要。特别是一旦SQL数据服务足够成熟以托管存储库，我们将拥有用于查询和操作此数据的所有不同协议和格式。客户端将能够通过ADO.NET数据服务进行查询和更新，使用JSON，POX，SOAP，MGraph等格式化消息。所有MGraph数据需求都是一个MGraph连接器，可以在数据库中获取它，从中可以以任何可想象的方式访问它。
您可以在我的文章中找到有关奥斯陆的更多信息： http://dvanderboom.wordpress.com/2009/01/17/why-oslo-is-important/
答案 3 :(得分：0)
...... JSON没做什么呢？
答案 4 :(得分：0)
我想知道为什么MGraph总是与XML相比而不是YAML，它看起来更相似。为什么我们经常重新发明轮子是无知还是盲目？
P.S：这就是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 ] }
}
]
}