Что вы думаете о Microsoft Осло MGraph?

Question

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?

Answer 1

Вот часть мыслей Джеймса Кларка о M :

"Я вижу несколько основных вещей, отсутствующих в M, чье отсутствие может быть приемлемым для приложения базы данных M, но которое будет существенным препятствием для других приложений M. Наиболее фундаментальным является порядок. M имеет два типа составных значений , коллекции и сущности, и оба они неупорядочены. В XML неупорядоченное является плохим отношением упорядоченного. Атрибуты неупорядочены, но атрибуты не могут иметь структурированные значения. Элементы имеют структуру, но в данном случае нет никакого способа сказать, что порядок дочернего элементы не являются существенными. Отсутствие поддержки неупорядоченных данных, очевидно, является слабостью XML для многих приложений. С другой стороны, порядок одинаково важен для других приложений. Очевидно, что вы можете подделать порядок в M, имея поля индекса в сущностях и такие как. Но это все еще подделка. Хороший язык моделирования должен поддерживать как упорядоченные, так и неупорядоченные данные первоклассным способом. Эта проблема, пожалуй, самая фундаментальная, поскольку она влияет на модель данных. * 10 07 *

Еще одна область, где М кажется слабой, это личность. В абстрактной модели данных сущности имеют идентичность независимо от значений их полей. Но система типов заставляет меня говорить об идентичности в стиле SQL, создавая искусственные поля, которые дублируют внутреннюю идентичность сущности. Хуже того, рамки для идентификации - это экстенты, которые являются плоскими таблицами. С этим связана поддержка иерархии. График является более общей моделью данных, чем дерево, поэтому я рад, что у меня есть графики, а не деревья. Но когда я имею дело с деревьями, я хочу иметь возможность сказать, что граф - это дерево (что равносильно указанию ограничений на идентичность узлов в графе), и я хочу иметь возможность работать с ним как с деревом. В частности я хочу иерархические пути.

Одной из сильных сторон XML является то, что он обрабатывает как документы, так и данные. Это важно, потому что мир не делится аккуратно на документы и данные. У вас есть данные, которые содержат документы и документ, который содержит данные. Главное, что вам нужно для аккуратного моделирования документов - это смешанный текст. Как вы собираетесь поддерживать документы в М? Отсутствие поддержки заказа является серьезной проблемой, поскольку заказ является нормой для документов.

С этим связан вопрос, как M и XML сочетаются друг с другом. Я считаю, что есть канонический способ представления значения M в виде документа XML. Но если у вас есть данные в формате XML, как вы выражаете их в M? Во многих случаях вы захотите перевести свою XML-структуру в M-структуру, которая аккуратно моделирует ваши данные. Но вы не всегда хотите тратить время на это, и если ваш XML содержит документоподобный контент, он станет уродливым. Возможно, вам лучше представить куски XML как простые значения в M (как и в мире JSON, вы часто получаете строки, содержащие куски HTML). М должно сделать это легко. Вы можете элегантно решить эту проблему с помощью RELAX NG (я знаю, что этого не произойдет, учитывая приверженность Microsoft XSD, но это интересный мысленный эксперимент): предоставьте функцию, которая позволяет ограничить простое значение для соответствия шаблону RELAX NG, выраженному в компактном синтаксисе (с компактным синтаксисом, возможно, настроенным для согласования с остальным синтаксисом М) и использованием репертуара простых типов М. в качестве библиотеки типов данных RELAX NG.

Наконец, существует проблема стандартизации. На мой взгляд, достижение XML не является в первую очередь техническим. Это социальный вопрос: заставить огромный круг сообществ согласиться использовать общий формат. Стандартизация была решающим фактором в достижении этого соглашения. XML никуда бы не пошел как формат одного поставщика. Было поразительно, что в беседах об Осло на PDC было несколько упоминаний об открытом исходном коде и о том, как Microsoft включила эту спецификацию в свое обещание открытой спецификации, чтобы включить реализации с открытым исходным кодом, но не упомянула о стандартизации. Я могу понять это: если бы я был Microsoft, я бы точно не хотел повторять опыт XSD или OOXML. Но открытый исходный код не заменяет стандартизацию.

«

Читать здесь Статья в блоге Джеймса Кларка о языке моделирования Осло .

Answer 2

В ответ на мысли Джеймса Кларка о М:

Я также вижу некоторые вещи, отсутствующие в М и Осло, но не совсем то же самое.

Было бы неплохо иметь некоторую гарантию того, что 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/

Answer 3

Я ничего не могу поделать, но я чувствую, что Осло - это решение, которое ищет действительно превосходную конкретную проблему. Я искренне надеюсь, что они найдут это.

У меня также возникло ощущение, что им нужно что-то веселое, чтобы раскрутить этот PDC этого года.

Answer 4

Интересно, почему MGraph всегда сравнивают с XML вместо YAML, который выглядит намного более похожим. Это невежество или слепота, почему мы регулярно изобретаем колёса?

P.S: Вот как может выглядеть 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 ] }
    }  
  ]  
}

Answer 5

... и что он делает, чего не делает JSON?