Сериализация графа зависимостей в XML
Что бы вы взяли на себя XML-файл, который содержит определенные элементы, которые ссылаются на другие элементы. Фон для этих вопросов - это технологическое дерево (график), сериализованное в виде XML-документа. Например, техническая "Пушка" обязательна для двух других узлов (элементов) "Железо" и "Порох".
Источник: http://www.amazon.com/Programming-Game-Example-Mat-Buckland/dp/1556220782
2 ответа
По своей природе XML вводит древовидную структуру в документ. Если отношение между элементом и его дочерними узлами считается определением "позволяет создавать", то у вас возникнет проблема, когда вы столкнетесь с ситуацией, когда на определенные объекты ссылаются более одного раза. Вам придётся указывать их дважды, без очевидного способа сказать, что они представляют собой одно и то же.
Давайте посмотрим на Железо из вашего примера:
<iron>
<cannons/>
<guns/>
</iron>
Никаких проблем там, однако, у Вуда не будет...
<wood>
<forge/>
<arrows/>
<guns/>
</wood>
guns элемент появляется и здесь. Представленное выше представление очень простое, но, возможно, с каждым элементом будет связано гораздо больше данных, и вы захотите избежать повторения. Вы также столкнетесь с проблемами, когда ваш граф будет содержать циклы, хотя я полагаю, что он не будет действительным в любом случае, учитывая семантику. Также обратите внимание, что древесина является прямым требованием к оружию, но оружие также косвенно зависит от дерева через железо. Это станет сложно представлять.
Ряд вещей может быть сделано. Прежде всего, каждый элемент и содержащаяся в нем структура могут быть размещены отдельно в XML-документе, а затем как-то ссылаться...
<guns itemId="1">
<!-- embedded structure -->
</guns>
...
<iron>
<item>1</item>
</iron>
<wood>
<item>1</item>
</wood>
Тем не менее, это оставляет вас на усмотрение программного разрешения таких ссылок. Преимущества XML, такие как инструменты синтаксического анализа, XSLT и привязка объектов, частично утрачены.
Другими вариантами было бы связать элементы с помощью XLink, что здесь вполне естественно. Или используйте XInclude, чтобы определить вещи только один раз, а затем включить их в разных местах. Ваш "встроенный" XML с разрешенными включениями все равно будет содержать все дубликаты данных. Но, по крайней мере, теперь это уже не может стать противоречивым.
Но это только один из способов взглянуть на это. Вместо того, чтобы пытаться получить ту же направленность в дереве XML, что и на вашем графике, как насчет изменения направления? Вместо отношения "позволяет создавать" вы можете создать отношения "требует".
Возвращаясь к Железу:
<iron>
<forge/>
</iron>
Теперь вы знаете, что Железу нужна Кузница. Оружие:
<guns>
<gunpowder/>
<iron/>
<wood/>
</guns>
Но проблема остается той же: вы не можете просто встраивать одну структуру в другую, потому что в какой-то момент одна и та же вещь понадобится в нескольких местах. Кузница требует Вуд, но и Оружие тоже.
XML работает для древовидных структур, но в тот момент, когда ваш граф не строго придерживается такой структуры, становится трудно представить его с помощью XML. По крайней мере, сложно в том смысле, что вы не получите от этого больших преимуществ и вам все равно придется много программировать самостоятельно.
Я не знаю ни одного (де) сериализуемого представления данных, которое бы идеально подходило для графиков любого вида. Есть программный пакет под названием Graphviz, который предназначен специально для рендеринга графиков; это с открытым исходным кодом, поэтому, возможно, документация и / или код может дать некоторые хорошие идеи.
Это ориентированный граф. Я уверен, что для этого есть много основанных на xml представлений, но на ум приходит graphml:
<graphml>
<graph id="techtree" edgedefault="directed">
<node id="gunpowder" />
<node id="iron" />
<node id="cannons" />
<edge source="gunpowder" target="cannons" />
<edge source="gunpowder" target="cannons" />
</graph>
</graphml>
Обратите внимание, что это только из памяти, вероятно, есть множество пространств имен и других необходимых вещей.