| |
 |
 |
 |
|
 |
Home
MS Concept
Categories:
constants:
|
Roles
Meshy Space base object ms:unit has many relations.
The client MAY understand these relations. The relations have a Role,
and end in a unit of a certain Type.
See also the base Roles.
The is attribute of the ms:has elements
in a ms:unit describe the relation. When that value
is in the msc: namespace, you will find it described below.
msc:Role/BasedOn- To be able to produce this unit, other units where used. For instance,
when this is compiled code, it may refer to the source code. It may
also refer to units which describe the configuration of tools which were
used, or servers where the production was run.
It MAY be useful to inspect the units where your parent is based on.
msc:Role/Contains- The reverse of the
parent relation: it may refer to itself,
or to units one level lower in the data structure defined by the
Concept.
For instance, a unit of type msc:Role/Collection
contains Collection sub-sets, but also Products and Actions. It will not
contain Stores.
msc:Role/Author- Refers to a
msc:Type/Identity.
Who or which process has created the payload for this unit (may be more
than one). Although optional, this may be very useful for debugging.
It is also required for licenses to be active. Defaults to the
Creator of the parent.
msc:Role/Breaks- Signals that the application of this unit will break the application
of other units, when they are in use in your environment. Administrator
intervention or a
--force may be needed to decide whether
to proceed.
msc:Role/Follows- This unit is a logical follow-up of the referred unit(s). For
instance, a previous document version or a previous software
release.
The unit's ms:revision is not to be used to manage
releases: the newest revision is the only valid state of the
unit. There are no parallel unit revisions in the same space.
It is the client's choice whether takes an action when it receives a
unit which follows some other unit. A deprecation of the previous
version may happen soon to force actions.
msc:Role/Owner- Refers to a
msc:Type/Identity.
The owner, possibly more than one, has special access rules
to the unit. This defaults to the owner(s) of the parent
unit. Either you list all owners, or use the default: you cannot
selectively take a sub-set of owners of the parent.
msc:Role/Publisher- Refers to a
msc:Type/Identity.
Who or which process has connected this unit to its parent: has made
this unit visible.
Units MAY get re-published: have more than one Publisher. For instance,
when someone feels that they need to be repackaged, signed with a
stronger algorithm, and so on. In such case, it is RECOMMENDED to keep
reference to the original Publisher.
msc:Role/Replaces-
- A bit stronger than simply 'Follows': the receiving party is advised
to remove the other unit when it is in use. What will need to happen
to achieve it, is outside the scope of Meshy Space (unless the unit
is a
msc:Type/)
msc:Role/Requires-
- Used to optimize the exchange of units: inform the client to request
for other units before attempting to use the content of this unit.
(Expect bi-directional dependencies). The requirements may refer to
software configurations or system names.
The when attribute of the ms:has
relation may help you in very convenient ways.
msc:Role/Rules- Refers to
msc:Type/Rules.
Defaults to the rules of the parent unit. The referred
rule-set describes who can access which relations, and who can
take which actions on the unit. One unit SHALL have no more than
one rule relation, but rule role units MAY be nested.
msc:Role/Wallet- Refers to
msc:Type/Collection, which contains the
secret components of your Identities. The Rules of a Wallet are
by default more strict than for normal collections. It is crucial
enough to give such collection its own Role.
|