The Default Profile is a direct implementation of the Core RAS defined in the specification.
Many assets can be packaged using the Default Profile, such as a business process, an Eclipse plug-in, a model, ...
xmi:ordered=true
property order is (these are role names)
1. context
2. descriptorGroup
This node represents the classification section of the asset.
Each asset is described by one or more groups of {name, value} pair descriptors called descriptor groups.
Each descriptor group may be defined by a Classification Schema. The classification section contains sets of descriptors that are defined by different schemas (at least one such set).
The classification section also identifies the context(s) for which the asset may be relevent or reused.
This model does not reflect all possible classification schemas. To accomplish this the DescriptorGroup may reference any schema that is external to the asset's specification.
xmi:ordered=true
property order is (these are role names)
1. context
2. descriptorGroup
This node represents the classification section of the asset.
Each asset is described by one or more groups of {name, value} pair descriptors called descriptor groups.
Each descriptor group may be defined by a Classification Schema. The classification section contains sets of descriptors that are defined by different schemas (at least one such set).
The classification section also identifies the context(s) for which the asset may be relevent or reused.
This model does not reflect all possible classification schemas. To accomplish this the DescriptorGroup may reference any schema that is external to the asset's specification.
xmi:ordered=true
association order is (these are role names)
1. profile
2. description
3. classification
4. solution
5. usage
6. relatedAsset
This is a descriptive container for an asset's artifacts. The artifacts may include models, source code, requirements, test cases, documentation, and so on.
Every RAS manifest document begins with a single Asset element. This element defines the identity of the reusable software asset.
An asset package is always in RAS format. However, it may not be RAS-compliant, meaning it passes all integrity constraints as documented in RAS (e.g., required content supplied).
An asset package contains or references the artifacts of the asset itself. The artifacts of the asset are the things that are actually reused. Some artifacts are descriptive content which helps the Asset Conumer understand the asset, and provide guidance on how to apply the asset. This guidance may be in the form of documentation, or may be executable install programs or scripts that automate the injection of an asset's artifacts into another project (such binaries can be included as part of the descriptive content of the asset's package).
Assets vary in their size, complexity, and variability.
The asset package, as a whole, should provide enough information to allow the Asset Consumer to decide if he/she wants to purchase/use the asset.
The name identifies the asset in a few words and is intended for human consumption, whereas the id attribute is expected to contain a globally unique identifier and is used by tooling to distinguish assets.
An asset's name and short description are typically the first pieces of information that potential consumers see when searching asset repositories. An asset's name should reflect the general solution strategy of the asset and optionally the problem that it addresses.
The date attribute contains a valid date using the default XML format (YYYY-MM-DD). The date indicates the date that the asset is ready to be used by asset consumers.
The state attribute indicates the state that the asset is currently in. This is intended primarily for asset certification workflows as an asset is undergoing reviews in preparation to be published in a repository.
The asset's version attribute can be any string and is used to compare two assets with the same id attribute.
The asset's access rights attribute can be any string which describes the permissions of asset consumers for interacting with the asset such as viewing or using.
The short description should be suitable for use in a line item where multiple asset names and short descriptions are displayed to a potential consumer.
xmi:ordered=true
association order is (these are role names)
1. profile
2. description
3. classification
4. solution
5. usage
6. relatedAsset
This is a descriptive container for an asset's artifacts. The artifacts may include models, source code, requirements, test cases, documentation, and so on.
Every RAS manifest document begins with a single Asset element. This element defines the identity of the reusable software asset.
An asset package is always in RAS format. However, it may not be RAS-compliant, meaning it passes all integrity constraints as documented in RAS (e.g., required content supplied).
An asset package contains or references the artifacts of the asset itself. The artifacts of the asset are the things that are actually reused. Some artifacts are descriptive content which helps the Asset Conumer understand the asset, and provide guidance on how to apply the asset. This guidance may be in the form of documentation, or may be executable install programs or scripts that automate the injection of an asset's artifacts into another project (such binaries can be included as part of the descriptive content of the asset's package).
Assets vary in their size, complexity, and variability.
The asset package, as a whole, should provide enough information to allow the Asset Consumer to decide if he/she wants to purchase/use the asset.
xmi:ordered=true
property order is (these are role names)
1. artifact
An asset provides a solution, which is found in a collection of artifacts. The <solution> element in a manifest is a simple container for all the artifact references of the asset. It is a required element and specifies no attributes. The <solution> element specifies only <artifact> child elements.
xmi:ordered=true
property order is (these are role names)
1. artifact
An asset provides a solution, which is found in a collection of artifacts. The <solution> element in a manifest is a simple container for all the artifact references of the asset. It is a required element and specifies no attributes. The <solution> element specifies only <artifact> child elements.
xmi:ordered=true
property order is (these are role names)
1. description
2. artifactContext
3. artifactDependency
4. variabilityPoint
5. artifactType
6. artifact
An artifact is a work product that can be created, stored and manipulated by asset producers/consumers and by tools. An artifact is either an actual file located in the asset's package, or represents a logical entity that contains at least one child artifact that is an actual file. An <artifact> element must specify minimally a name or a reference attribute. The name is required for artifacts that represent logical entities. The reference is required for artifacts that specify actual file or work products that are part of the asset's packaging.
An artifact may specify child artifacts. A child artifact uses the same <artifact> element. If the artifact is a logical artifact then it must specify a name and have at least one descendent artifact that is an actual file reference.
The name, type, and reference attributes are optional. This was done to allow large numbers of artifacts to be added by tooling but for which each specific name may not be known. In this scenario the name may have become the filename, but that would be redundant with the reference attribute. The reference attribute remains optional to allow <artifact> elements to contain other <artifact> elements and not reference anything on the filesystem or elsewhere.
Artifacts that represent actual files can be of any type. That is they can be any type of file (binary, plain text, etc.). An artifact referenced in a manifest can optionally declare a primary type, which is captured in the type attribute. The primary type can affect how tools process the artifact. In addition to a primary type an artifact can specify any number of secondary types. Each secondary type is specified with a <artifact-type> child element (see <artifact-type>).
In practice the primary types tend to map to file extensions. For instance if we had a file with the name web.xml its primary type is XML and its secondary type may be J2EE Web Configuration.
The primary type list maps file extensions to type names. There may be many file extensions to the same type name. It is also possible to have many type names to the same file extension. In this case the tooling should provide a way for the user to reconcile. For instance, you may have a file named usecases.doc. The .doc extension may map to a "Microsoft Word" type and it may map to a "WordPerfect" type.
This optional attribute is used to identify an artifact's version.
With ever-increasing needs for security an artifact may be encrypted with a specific algorithm. The digest-name attribute contains the name from such encryption activities.
With ever-increasing needs for security an artifact may be encrypted with a specific algorithm. The digest-value attribute contains the value from such encryption activities.
A specific artifact may have its own permission and usage rights associated with it. The access-rights attribute captures artifact-level permission information. RAS does not specify the format of this permission information.
xmi:ordered=true
property order is (these are role names)
1. description
2. artifactContext
3. artifactDependency
4. variabilityPoint
5. artifactType
6. artifact
An artifact is a work product that can be created, stored and manipulated by asset producers/consumers and by tools. An artifact is either an actual file located in the asset's package, or represents a logical entity that contains at least one child artifact that is an actual file. An <artifact> element must specify minimally a name or a reference attribute. The name is required for artifacts that represent logical entities. The reference is required for artifacts that specify actual file or work products that are part of the asset's packaging.
An artifact may specify child artifacts. A child artifact uses the same <artifact> element. If the artifact is a logical artifact then it must specify a name and have at least one descendent artifact that is an actual file reference.
xmi:ordered=false
property order is (these are role names)
1. artifactActivity
2. contextRef
3. assetActivity
{optional}
xmi:ordered=false
property order is (these are role names)
1. artifactActivity
2. contextRef
3. assetActivity
xmi:contentType=mixed
OPTIONAL
xmi:contentType=mixed
xmi:ordered=true
property order is (these are role names)
1. description
2. descriptorGroup
{required}
xmi:ordered=true
property order is (these are role names)
1. description
2. descriptorGroup
xmi:ordered=true
property order is (these are role names)
1. activity
xmi:ordered=true
property order is (these are role names)
1. activity
xmi:ordered=true
property order is (these are role names)
1. description
2. descriptor
A descriptor group is simply a container for a related group of <descriptor>s. A <description> child element can be used to provide a description of the descriptor group.
The name attribute describes the group of <descriptor>s.
The reference contains a pointer to a document, which describe the profile in more detail.
ordered
xmi:ordered=true
property order is (these are role names)
1. description
2. descriptor
A descriptor group is simply a container for a related group of <descriptor>s. A <description> child element can be used to provide a description of the descriptor group.
xmi:contentType=mixed
A <descriptor> is a simple key/value pair that emphasizes certain qualities and characteristics of the asset. Often these are searchable and may be used for asset discovery and evaluation.
The value is captured as the elements content in plain text. A <descriptor> may be associated with a specific <context> through the context association. This means that the key and value should be thought of in the specified <context>. The value of the context association must reference an existing id of a <context> element.
xmi:contentType=mixed
A <descriptor> is a simple key/value pair that emphasizes certain qualities and characteristics of the asset. Often these are searchable and may be used for asset discovery and evaluation.
The value is captured as the elements content in plain text. A <descriptor> may be associated with a specific <context> through the context association. This means that the key and value should be thought of in the specified <context>. The value of the context association must reference an existing id of a <context> element.
An ArtifactContext> element associates a Context to an Artifact.
An ArtifactContext> element associates a Context to an Artifact.
An ArtifactDependency identifies a dependent Artifact. The dependent Artifact must be another Artifact defined in the manifest. See the Artifact description. This is a child element to the Artifact element. The dependencyType attribute describes artifact dependencies such as design time dependency or a compile time or runtime.
An ArtifactDependency identifies a dependent Artifact. The dependent Artifact must be another Artifact defined in the manifest. See the Artifact description. This is a child element to the Artifact element. The dependencyType attribute describes artifact dependencies such as design time dependency or a compile time or runtime.
xmi:ordered=true
property order is (these are role names)
1. activity
xmi:ordered=true
property order is (these are role names)
1. activity
xmi:ordered=true
property order is (these are role names)
1. activity
xmi:ordered=true
property order is (these are role names)
1. activity
xmi:ordered=true
property order is (these are role names)
1. description
2. activity
3. variabilityPointBinding
{required}
{optional}
{optional}
xmi:ordered=true
property order is (these are role names)
1. description
2. activity
3. variabilityPointBinding
xmi:contentType=mixed
A <variability-point> is a conceptual spot in an artifact that is expected to be altered by the asset consumer. It describes where and what in the artifact can be modified. Each <variability point> specifies a name, which describes it and an identifier, which is used to reference it from other elements in the manifest. A variability point may be associated with a context and its optional context association must therefore specify a valid id of a <context> element in the document.
{required}
xmi:contentType=mixed
A <variability-point> is a conceptual spot in an artifact that is expected to be altered by the asset consumer. It describes where and what in the artifact can be modified. Each <variability point> specifies a name, which describes it and an identifier, which is used to reference it from other elements in the manifest. A variability point may be associated with a context and its optional context association must therefore specify a valid id of a <context> element in the document.
{required}
xmi:ordered=true
property order is (these are role names)
1. description
2. relatedProfile
An asset is defined by one profile; a profile describes the asset's type. The profile can have different versions and should declare its lineage or ancestry from other profiles. The related-profile captures information on the profile's lineage.
The Profile element in the XML schema includes information about the format of the manifest itself. It identifies exactly which version of this specification and which RAS profile should be used to validate the manifest document for compliance. A profile defines the structure and semantics of an asset's manifest document. Every RAS manifest document must identify the profile that can be used to validate it. Every profile is derived from another profile with the one exception being the original Core profile, which was defined by the first version of the RAS and for which there is no XML Schema produced. Profiles can extend directly from Core RAS or from any other profile such as the Default Profile for version 2.1. These derived profiles can only add elements and attributes to the manifest's XML Schema, and/or associate new semantics to existing elements. They cannot remove elements or attributes from the XML Schema. In general derived profiles are more restrictive. This attempts to make it easier for tools to gracefully handle assets created with profiles defined after the tooling was created.
Each profile specifies a human readable name that reflects the purpose or scope of the profile.
The id-history is a composite key that is made up of the profile id followed by the profile ids of all the profiles that it is derived from. A profile is derived from exactly one parent profile with the notable exception of the first and original Core profile introduced with the RAS 1.0 specification.
As an example the following is the id history for the RAS Default profile version 2.1:
F1C842AD-CE85-4261-ACA7-178C457018A1::31E5BFBF-B16E-4253-8037-98D70D07F35F
It indicates that the profile identified by: "F1C842AD-CE85-4261-ACA7-178C457018A1" is derived from the profile identified by "31E5BFBF-B16E-4253-8037-98D70D07F35F", which is the Core profile defined in the first version of the RAS specification.
If a new profile was defined a new GUID would be generated and it would be pre-pended to the id-history of the profile that it derived from. For example it might be:
F8C49799-25C9-4312-B798-D5D2E1FBC656::F1C842AD-CE85-4261-ACA7-178C457018A1::31E5BFBF-B16E-4253-8037-98D70D07F35F
This new profile defines a new set of elements, attributes and semantics that extend those already defined by all of the other profiles in the id-history.
The version-major and version-minor attributes help identify the profile version, and in particular helps distinguish it from previous profiles with the same name. These attributes are integers. Often these two values are combined together with a period, and form what appears to be a floating-point number. For example a version major of 2, and version minor of 1 might be written as version 2.1.
Changes in the version major and version minor values should be made when a profile is updated and when its name remains the same. This would be the case when a profile is updated but its target purpose or scope, and hence name remains the same.
The version-major and version-minor attributes help identify the profile version, and in particular helps distinguish it from previous profiles with the same name. These attributes are integers. Often these two values are combined together with a period, and form what appears to be a floating-point number. For example a version major of 2, and version minor of 1 might be written as version 2.1.
Changes in the version major and version minor values should be made when a profile is updated and when its name remains the same. This would be the case when a profile is updated but its target purpose or scope, and hence name remains the same.
xmi:ordered=true
property order is (these are role names)
1. description
2. relatedProfile
An asset is defined by one profile; a profile describes the asset's type. The profile can have different versions and should declare its lineage or ancestry from other profiles. The related-profile captures information on the profile's lineage.
The Profile element in the XML schema includes information about the format of the manifest itself. It identifies exactly which version of this specification and which RAS profile should be used to validate the manifest document for compliance. A profile defines the structure and semantics of an asset's manifest document. Every RAS manifest document must identify the profile that can be used to validate it. Every profile is derived from another profile with the one exception being the original Core profile, which was defined by the first version of the RAS and for which there is no XML Schema produced. Profiles can extend directly from Core RAS or from any other profile such as the Default Profile for version 2.1. These derived profiles can only add elements and attributes to the manifest's XML Schema, and/or associate new semantics to existing elements. They cannot remove elements or attributes from the XML Schema. In general derived profiles are more restrictive. This attempts to make it easier for tools to gracefully handle assets created with profiles defined after the tooling was created.
xmi:ordered=true
property order is (these are role names)
1. description
This is one of the Profile elements child elements which provides human readable information about each of the profiles in the Profile::idHistory attribute.
This node captures the history of the profile by describing the profile's genealogy. This element includes many of the same attributes found in the Profile element.
This should be the name of the profile that is referenced by the profile id in the <profile>::id-history attribute.
This id is the profile id for a profile which is an ancestor to the current profile and which is not the <profile> id from this document.
The version-major, and version-minor attributes contain the ancestor profile's version information.
The version-major, and version-minor attributes contain the ancestor profile's version information.
The parent-id describes the profile's ancestor from which it was derived.
The reference contains a pointer to a document, which describe the profile in more detail.
xmi:ordered=true
property order is (these are role names)
1. description
This is one of the Profile elements child elements which provides human readable information about each of the profiles in the Profile::idHistory attribute.
This node captures the history of the profile by describing the profile's genealogy. This element includes many of the same attributes found in the Profile element.
xmi:contentType=mixed
The <description> element is a simple container for a human readable description of the asset. This description is expected to be about one or two paragraphs in length, however there is no restriction on size specified by this document. It describes in some detail the problem that the asset addresses and its main solution strategies.
It is possible for the content of the <description> element to be formatted with HTML. The <description> element is global in the XML Schema and is referenced in multiple places.
This element does not have any attributes but supports multi-line text.
xmi:contentType=mixed
The <description> element is a simple container for a human readable description of the asset. This description is expected to be about one or two paragraphs in length, however there is no restriction on size specified by this document. It describes in some detail the problem that the asset addresses and its main solution strategies.
It is possible for the content of the <description> element to be formatted with HTML. The <description> element is global in the XML Schema and is referenced in multiple places.
This element does not have any attributes but supports multi-line text.