Что вы думаете о Microsoft Осло MGraph?
MGraph - отличный формат текстовых данных, представленный Microsoft "Осло".
Как вы думаете, у него есть шанс стать таким же широким, как у XML сегодня?
Пример (Google Geocode):
{
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 "Осло" MGraph - следующий XML?
5 ответов
Вот часть мыслей Джеймса Кларка о М:
"Я вижу несколько основных вещей, отсутствующих в M, чье отсутствие может быть приемлемым для приложения базы данных M, но которое будет существенным препятствием для других приложений M. Наиболее фундаментальным является порядок. У M есть два типа составной стоимости, коллекции и сущности, и оба они неупорядочены. В XML неупорядоченное является плохим отношением упорядоченного. Атрибуты неупорядочены, но атрибуты не могут иметь структурированные значения. Элементы имеют структуру, но в этом случае нет никакого способа сказать, что порядок дочерних элементов не является Существенное. Отсутствие поддержки неупорядоченных данных, очевидно, является слабостью XML для многих приложений. С другой стороны, порядок одинаково важен для других приложений. Очевидно, что вы можете подделать порядок в M, имея индексные поля в сущностях и тому подобное. Но он все еще притворяется. Хороший язык моделирования должен поддерживать как упорядоченные, так и неупорядоченные данные первоклассным способом. Эта проблема, пожалуй, самая фундаментальная, поскольку она влияет на модель данных.
Другая область, где M кажется слабой - это личность. В абстрактной модели данных сущности имеют идентичность независимо от значений их полей. Но система типов заставляет меня говорить об идентичности в стиле SQL, создавая искусственные поля, которые дублируют внутреннюю идентичность сущности. Хуже того, рамки для идентификации - это экстенты, которые являются плоскими таблицами. С этим связана поддержка иерархии. График является более общей моделью данных, чем дерево, поэтому я рад, что у меня есть графики, а не деревья. Но когда я имею дело с деревьями, я хочу быть в состоянии сказать, что граф - это дерево (что равнозначно указанию ограничений на идентичность узлов в графе), и я хочу иметь возможность работать с ним как с деревом. В частности я хочу иерархические пути.
Одним из преимуществ XML является то, что он обрабатывает как документы, так и данные. Это важно, потому что мир не делится аккуратно на документы и данные. У вас есть данные, которые содержат документы и документ, который содержит данные. Главное, что вам нужно для аккуратного моделирования документов - это смешанный текст. Как вы собираетесь поддерживать документы в М? Отсутствие поддержки заказа является серьезной проблемой, потому что заказ является нормой для документов.
С этим связан вопрос, как M и XML сочетаются друг с другом. Я считаю, что есть канонический способ представления значения М в виде документа XML. Но если у вас есть данные в формате XML, как вы выражаете их в M? Во многих случаях вы захотите перевести свою XML-структуру в M-структуру, которая четко моделирует ваши данные. Но вы не всегда хотите тратить время на это, и если ваш XML имеет документоподобный контент, он станет уродливым. Возможно, вам лучше представить фрагменты XML в виде простых значений в M (как и в мире JSON, вы часто получаете строки, содержащие фрагменты HTML). М должно сделать это легко. Вы можете элегантно решить эту проблему с помощью RELAX NG (я знаю, что этого не произойдет, учитывая приверженность Microsoft XSD, но это интересный мысленный эксперимент): предоставьте функцию, которая позволяет ограничить простое значение для соответствия шаблону RELAX NG, выраженному в компактном синтаксисе (с компактным синтаксисом, возможно, настроенным для согласования с остальным синтаксисом M) и использования репертуара простых типов M в качестве библиотеки типов данных RELAX NG.
Наконец, есть проблема стандартизации. На мой взгляд, достижение XML не является в первую очередь техническим. Это социальный вопрос: заставить огромное количество сообществ согласиться использовать общий формат. Стандартизация была решающим фактором в достижении этого соглашения. XML никуда бы не пошел как формат одного поставщика. Поразительно, что в разговорах об Осло на PDC было несколько упоминаний об открытом исходном коде и о том, как Microsoft включила эту спецификацию в свое Обещание открытой спецификации, чтобы включить реализации с открытым исходным кодом, но не упомянула о стандартизации. Я могу понять это: если бы я был Microsoft, я бы точно не хотел повторять опыт XSD или OOXML. Но открытый исходный код не заменяет стандартизацию.
"
Читайте здесь статью в блоге Джеймса Кларка на языке моделирования Осло.
В ответ на мысли Джеймса Кларка о М:
Я также вижу некоторые вещи, отсутствующие в М и Осло, но не совсем то же самое.
Было бы неплохо иметь некоторую гарантию того, что M сохранит порядок сохранения сущностей в коллекциях. Однако то, как вы хотите заказать элементы, является деталью реализации. Если у вас есть заказанная коллекция в M, и вы сохраняете это в базе данных, как вы поддерживаете их там? Единственный способ состоит в том, чтобы сделать некоторые предположения о форме данных, добавить столбец в таблицу, которую вы не указали, и в этом случае имеет больше смысла полностью контролировать форму вашей структуры данных.
То же самое касается личности. Причина, по которой у нас есть идентификатор объекта в памяти, заключается в том, что каждый объект выделяет в памяти свое место и имеет этот адрес в памяти, чтобы однозначно идентифицировать его. Однако при сохранении в базе данных эта информация больше не актуальна, и вам необходим некоторый столбец или комбинация столбцов, чтобы однозначно идентифицировать эту запись, чтобы служить ее первичным ключом. Если вы не укажете это, то M должен придумать для вас столбец, и у вас не будет ссылки на него, за исключением, возможно, какого-то трюка, который может быть трудно обнаружить. Другими словами, нет "внутренней идентичности"; всегда есть данные, которые явно идентифицируют его.
Документы и данные не две разные вещи. XML не обрабатывает документы как таковые; это просто представляет иерархические данные, и документы составлены из этого. Пока данные структурированы, они могут быть представлены в M так же, как вы можете писать классы для различных частей иерархии и ссылаться на один тип из другого, чтобы объединить их в произвольно сложные деревья. По общему признанию, это легче объединить в XML, потому что это текст в свободной форме и нет реальной проверки, если вы не пишете схему XSD, но в этих случаях вы выполняете ту же работу, что и определение типов и отношений в классах кода.,
В конечном счете, M обрабатывает документы, для которых вы определяете структуру, и эта структура на самом деле не имеет никаких ограничений. Вопрос в том, насколько легко это сделать. Идея создания инструмента для разборки XML-документа и генерации M-схемы довольно хороша. Я полагаю, что было бы не сложно написать его, или чтобы Microsoft включила его в свою цепочку инструментов, когда она станет более зрелой. Что касается структуры, которая становится "уродливой", то если ваша структура данных действительно настолько сложна, то она и есть. Его схематизация имеет большие преимущества, то же самое в классах XSD или M или C#, но если ваша цель - сохранить ее в базе данных SQL Server (или, в частности, в репозитории Oslo), то это необходимо и целесообразно.
Я вполне уверен, что M и вспомогательная инструментальная цепочка превратятся в нечто удивительное и полезное. Очевидно, что сейчас многое отсутствует. Лично меня больше беспокоит тот факт, что M в настоящее время нацелен на моделирование на уровне реляционной, физической базы данных, а не на концептуальном уровне (например, Entity Framework), где для разработчика наиболее естественно начать моделирование. В конце концов, при написании классов для создания экземпляров объектов из MGraphs (цель и выходные данные для DSL) ваши классы могут быть определены совершенно иначе, чем они сохраняются. Особенно, если вы используете наследование в своих моделях.
Я согласен с вами по стандартизации. Это было бы чудесно. Тем не менее, я думаю, что это менее важно из-за того, что цель состоит в том, чтобы сохранить эти данные в хранилище Осло. Особенно когда службы данных SQL станут достаточно зрелыми для размещения репозитория, у нас будут разные протоколы и форматы для запросов и манипулирования этими данными. Клиенты смогут запрашивать и обновлять через службы данных ADO.NET, форматируя сообщения с помощью JSON, POX, SOAP, MGraph и так далее. Все данные MGraph нужны для подключения MGraph к базе данных, откуда к ним можно получить доступ любым доступным способом.
Вы можете найти больше информации об Осло в моей статье здесь: http://dvanderboom.wordpress.com/2009/01/17/why-oslo-is-important/
Я ничего не могу поделать, но я чувствую, что Осло - это решение, которое ищет действительно превосходную конкретную проблему. Я искренне надеюсь, что они найдут это.
У меня также возникло ощущение, что им нужно что-то веселое, чтобы поучаствовать в этом году.
Интересно, почему MGraph всегда сравнивают с XML вместо YAML, который выглядит гораздо более похожим. Это невежество или слепота, почему мы регулярно изобретаем колеса?
PS: Вот как может выглядеть YAML (без пользовательских типов данных и ссылок на узел 'p1', который YAML предоставляет в дополнение к JSON):
{
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 ] }
}
]
}