{des4:0} An attribute is a tuple of:
{des4:1} The "Attributes of an Object" (AoO) is a flat map (hash table) of zero or more attributes. Attribute keys within the AoO are unique. There is no particular limit on the size of the AoO.
{des4:2} Key is always a 7-bit ASCII string no longer than 510 characters, containing only characters between decimal 33 and 126.
{des4:3} As a convention the slash ('/') character can be used as a "path separator", emulating semantic hierarchy in the flat AoO list, with the leading '/' for root omitted. Cschem itself and most plugins will ignore such pseudo-hierarchy, and will handle slash without side effects. Nevertheless GUI implementations may present attributes as a tree and attribute conventions will use the pseudo-hierarchy to group attributes. If the first character of the key is with - or +, that alters attribute merging during compilation.. This is called attribute prefixing (the prefix is part of the key, e.g. when string comparing the key).
{des4:4} Each attribute has only one atomic value. The value can be changed (replaced) and interpreted as a whole. The value is one of: empty, scalar or array.
{des4:5} An attribute with an empty value should behave the same way as if the attribute was not present. The reason to have an explicit empty value is to provide a way to keep track on the compile-history of attributes.
{des4:6} A scalar value is a 7-bit ASCII string of arbitrary lengths, containing only characters between decimal 32 and 126, tab (\t) and newline (\n). The interpretation of the value should be detailed in the specification of the given attribute.
{des4:7}
An array value is a one-dimensional, contiguous (free of holes or missing items),
ordered list of values. Array members are indexed with positive integers
starting from 0. Index values can be represented on at most 31 bits, which
also means the largest array may not have more than 231 values.
{des4:8}
The format and interpretation of array values are the same as of the scalar
values. The interpretation of array indices is also attribute-specific.
{des4:9}
Each attribute has an unsigned 15 bit integer priority. Highest priority
is value 0, lowest priority is value 215-1.
{des4:10}
Whenever an attribute is going to be overwritten, the write action
should carry a priority. The write succeeds only if its priority value
is lower or equal to the the priority of the attribute in the target
AoO. When a write fails, the compile-history of the
attribute is still updated with the failed entry.
4.3. Attribute priority
from | to | description |
0 | 0 | Priority 0 shall be used for "hardwired" items the user shall not be able to change. |
1 | 100 | user, high tier for group_ref instance |
101 | 200 | user, high tier for group_ref original |
201 | 300 | user, normal for group_ref instance |
301 | 400 | user, normal for group_ref original |
401 | 500 | user, low tier for group_ref instance |
501 | 600 | user, low tier for group_ref original |
1001 | 10000 | plugin, high tier |
11001 | 20000 | plugin, normal |
21001 | 30000 | plugin, low tier |
31001 | 31100 | user, lowest tier |
{des4:12} Default user priority shall be 250: middle of normal user priority for instances.
{des4:13} Plugins that modify attributes shall use priority values between 1001 and 30000. These values should be assigned by the view , as a range of priority values for each plugin the view refers to. Each plugin should get three ranges, each range should be of 10 values; one from the high tier, one from the normal and one from the low tier section. E.g. a plugin may get the priority number ranges 1041-1050, 11041-11050 and 21041-21050.
{des4:14} Plugin ranges shall not overlap with other ranges. There should be an empty 10 value range between every two plugin ranges so that the user can use priority values in between plugins.
{des4:15} After the concrete model is compiled into the abstract model , each attributes of the abstract model has a compilation-history that describes how the final value of that specific attribute was affected by different sources of information. The complete compilation-history is stored in the source field, as an array (as specified below).
{des4:17} Attributes of abstract objects start with an empty compilation-history. Each successful write shall append and entry to the source array in the following format:
prio::type::source::description
{des4:18} where prio is the new priority, source is the identifier of the information source and description is a short, free form text in which the source describes the reason for the change.
{des4:16}{des4:19} Type and sources are specified in the following format:
{des4:51} First, all attributes of all concrete objects are copied into attributes of the abstract objects they contribute to. There are three ways the copy may happen depending on the first character of the concrete object attribute key:
{des4:20} Plugins are invoked in the order specified by the current view. The view also specifies a range of priorities the invoked plugin may use. Plugins that are invoked later shall have higher priority (lower integer priority value).
{des4:21} This means plugins invoked later can use, as input, attributes produced by plugins invoked earlier.
{des4:22} The same plugin can be present in the same view multiple times, but the view is a linear list, there are no loops. This means attribute-overwrite-loops can not form. (Such a loop would be two plugins A and B, A writing an attribute that is then input of B which writes another attribute that is input for A which then produces a new version of the attribute.)
{des4:23} Because of the unique priorities mandated by the view, it is also impossible that two plugins would attempt overwrite the same attribute with the same priority.
syntax | meaning |
---|---|
. | another attribute of the same object |
.. | an attribute of the parent group |
role | an attribute of the closest parent group with role attribute matching role, walking up the tree of group |
sheet | an attribute of the current schematics sheet |
{des4:50} .. and role can be combined to form a path (e.g. a full reference could be symbol/..::pcb/footprint).