From 1cb5fdc15c5f8399ca08377eb498f7c27c2eee85 Mon Sep 17 00:00:00 2001
From: Benjamin Paassen <bpaassen@techfak.uni-bielefeld.de>
Date: Thu, 6 Mar 2014 11:54:40 +0000
Subject: reworked the model classes according to manipulated GraphNode and
 removed some bugs resulting from a misunderstanding between abtract domain
 declarations and instances.

git-svn-id: file:///var/local/svn/basicwriter@29 daaaf23c-2e50-4459-9457-1e69db5a47bf
---
 src/model/domain/Class.hpp | 68 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 63 insertions(+), 5 deletions(-)

(limited to 'src/model/domain/Class.hpp')

diff --git a/src/model/domain/Class.hpp b/src/model/domain/Class.hpp
index 231bb80..6100214 100644
--- a/src/model/domain/Class.hpp
+++ b/src/model/domain/Class.hpp
@@ -16,26 +16,84 @@
     along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
 
-#ifndef _CLASS_HPP_
-#define _CLASS_HPP_
+#ifndef _OUSIA_MODEL_DOMAIN_CLASS_HPP_
+#define _OUSIA_MODEL_DOMAIN_CLASS_HPP_
 
 #include <memory>
+#include <string>
 #include <vector>
 
 #include <model/GraphNode.hpp>
+#include "ClassReferenceSet.hpp"
+#include "Field.hpp"
+#include "Layer.hpp"
 
 namespace ousia {
+namespace model {
 namespace domain {
 
+/**
+ * A class represents some semantic concept in a given domain that has
+ * structural relevance, like headings in a text. Classes are usually expected
+ * to be in a "tree-esque" structure: It is not really a tree, but we still
+ * think about classes as nodes with children, even though children might be
+ * nodes higher up the tree, which leads to cycles.
+ */
 class Class : public GraphNode {
 
 private:
-	std::vector<std::shared_ptr<Class>> children;
 
-};
+	std::vector<std::shared_ptr<ClassReferenceSet>> children;
+	std::vector<std::shared_ptr<Field>> fields;
+	std::vector<std::shared_ptr<Layer>> layers;
+
+public:
+	
+	Class(std::shared_ptr<GraphNode> parent = nullptr,
+			const std::string &name = "") :
+		GraphNode(GraphNodeType::Class, parent, name)
+	{
+		// Do nothing here
+	}
+
+	/**
+	 * The children of a given class are not resolved on parsing time but lazily
+	 * during document creation and validation time. This circumvents some
+	 * problems we would have otherwise like: How do we treat the case that
+	 * merging two domains adds more possible classes to some given category?
+	 * How do we treat references to linked domains?
+	 *
+	 * Thus we do not specify the children that are allowed but a sequence of
+	 * sets that define what set of classes is allowed at each point in the
+	 * children sequence. Please note that each ClassReferenceSet also stores
+	 * a cardinality, how many children, that are members of this set, have to
+	 * exist. Therefore this construction can be interpreted as a quasi finite
+	 * state automaton, e.g.:
+	 *
+	 * (class1|class2)* (class3){1,4}
+	 */
+	std::vector<std::shared_ptr<ClassReferenceSet>>& getChildren()
+	{
+		return children;
+	}
 
+	std::vector<std::shared_ptr<Field>>& getFields()
+	{
+		return fields;
+	}
+
+	/**
+	 * Layers specify the annotations that are allowed upon instances of this
+	 * class and its children.
+	 */
+	std::vector<std::shared_ptr<Layer>>& getLayers()
+	{
+		return layers;
+	}
+};
+}
 }
 }
 
-#endif /* _CLASS_HPP_ */
+#endif /* _OUSIA_MODEL_DOMAIN_CLASS_HPP_ */
 
-- 
cgit v1.2.3