General differences in the implementation
=========================================
Lycan use a 'flat' representation of OpenC2 objects based on Stix approach and terminology, which
does not reflect OpenC2 grammar. This is simple to translate into dictionary/json, because each
object is already in a sort of "dictionary" form since the beginning, even if its structure is
hidden by the definition of the Targets, Args, Actuators, ... 
It seems the Property is just a sort of type checker, that does not do nothing apart checking and
converting the data type. Data are indeed stored in Target/Actuators/Args types.
What is not clear so far, is the meaning of CustomProperty, which indeed holds several properties
as a sort of class or complex data type.

OpenC2lib follows the same grammar definition as the LS, so it is simpler for the developer to 
understand the structure of usage of each class, because this is described in the LS. On the
other hand, the heterogeneity of objects complicates their translation into dictionary/json, which
is because metaserialization is used. Further, openc2lib has a better way to convert several
object types into its own structures, which is not possible with Lycan.

> ISSUE                                                                                            <
> However, when trying to define a new Property based on a non-base type, the serialization fails. <
> (see for example, the definition of an assed_id as 'uuid.UUID' for acme) 											<
> This prevents the definition of additional Properties beyond what provided by the core library,  <
> hence forcing to more complex conversion and data checking.													<
> (I guess the return type is simple, and must be converted back into the type I need in my code)  <
> SOLUTION                                                                                         <
> The problem is the lack of documentation. Indeed, the .clean() funcion of a Property is          <
> functionally equivalent to a serialization method, and must return something which is            <
> serializable by the json module. Indeed, if I define the clean function so to return a str,      <
> everything works fine and I get my serialized version of the property.                           <

Lycan has no documentation, but just a single example of creating custom objects, plus more definitions
as part of the tests. The level of complexity is similar to openc2lib, but the addition of
more "properties" is not documented. Also the meaning and usage of properties is trickier than 
openc2lib data types (they do not really hold values, they are just used for type assignment and data
validation).

>>> WARNING <<<<
You can declare only one property object for each extension, otherwise the parsing method fails.
All additional parameters must be included in this unique definition.


>>> MEGA-BUG: The current way to define custom arguments use the profile name as property name  <<<
>>> in CustomArgs (see the example), and this prevent to embed the custom arguments into the    <<<
>>> profile name (because the tag "x-acme" has the "-" which is not allowed in variables!!!!    <<<
>>> The only way to escape this limitation is to pass the argument as a dictionary, which is    <<<
>>> not the best option according to the programming style of lycan.										<<<

The name of the nsid is repeated a number of times in the definition of args, actuators, and
targets, hence making errors more likely.
Also the definition of some fields is redundant (e.g., see how to create a Custom Target.




