# HG changeset patch
# User Thinker K.F. Li <thinker@codemud.net>
# Date 1307667020 -28800
# Node ID e790c6b2d5d9428f3ff16140242e3a11c93e5aba
# Parent  b0cc5da28141c4b5413cae9fec78ad61ac97c6be
doc for data struct description

diff -r b0cc5da28141 -r e790c6b2d5d9 docs/describe-data-struct.muse
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/describe-data-struct.muse	Fri Jun 10 08:50:20 2011 +0800
@@ -0,0 +1,32 @@
+Data struct own some relation-ship or logics internally.  Usually,
+they are described in code spreaded over the project.  The problem of
+code is deattach relationships from the data struct.  You don't see
+the relationship with definition of data struct alone.  You can also
+not get the relationship from the code easily.  So, we need a way
+to describe relationship in the definition of data struct to attach
+the information with data struct.
+
+Attaching relationship is not only easy to read, but also parse-able.
+Relationships are attached a part of definition of data struct.  They
+are not code, it means more easy to be parsed.  A lot of code can be
+generated automatically by tools.
+
+Persisted data (in secondary storage) is usually a tree with reference
+between branches while internal data struct is usually a group of
+interconnected objects.  We dont use persisted one directly because
+they are more hard to be used.  You need extra-logic to travel
+persisted data struct.  We need the code to convert persisted data
+struct to internal one and in reversed, but it is tedious.  With a
+language to describe data struct with attaching relationship, we can
+generate code for conversion of data struct from/to persisted to/from
+internal ones.
+
+** Construction
+
+ - types
+ - relationships
+   - reference
+   - dependency
+ - constrain
+ - condition
+ - path