-
-
Notifications
You must be signed in to change notification settings - Fork 4
meta
The unified wasp code / data model can represent a wide variety of data layouts. Different kinds of nodes are reflected via different types.
However since attributes, methods and fields are unified, and comments are not part of the analysis step, extra
information such as annotations can at times be stored in the meta
field of a node. This is usually only needed if
very specific data layout considerations are required, e.g. if an xml file is to be represented not just semantically
but verbatim.
The meta field should give the node graph the power to naturally represent almost all kind of data, including cyclic labled graphs via wasp references.
Since the meta field is a node itself, it can store arbitrary data including maps.
Tools using the meta field should assume/enforce it to be a map and add itself (and a potentially existing meta node) as key:
if(not node.meta) node.meta=*new Node();
(*node.meta)["my_annotation"]=my_annotation;
An example would be a node of kind list, where all children represent elements in the list, but extra information other than the type may be stored, such as whether the list is already ordered or whether all elements adhere to a specific class and if this generic template type is enforced and validated.
How to handle tools trying to use the same meta/annotation key?