This seems rather serious, but perhaps some OCL FTF person will reassure me that it's not:

The UML 2 Superstructure spec defines additional query operations for a number of metaclasses. For example, the following query is defined for the metaclass Element:

Element::allOwnedElements(): Set(Element);
allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

Another example is the query defined for ProtocolTransition:

context Region::belongsToPSM () : Boolean
result = if not stateMachine->isEmpty() then
oclIsTypeOf(ProtocolStateMachine)
else if not state->isEmpty() then
state.container.belongsToPSM ()
else false

Notice the different forms used to define these two queries. The first one uses the name of the operation to store the result while the second uses the OCL reserved word "result". In the spec, there many queries that use the first form and only three cases of the latter form.

A review of the OCL spec with respect to this issue – as far as I can tell – indicates that there are three valid ways of specifying a query as shown by the following two examples:

(1) using body expressions (note the 'body:' prefix in the second line):

context Element::allOwnedElements(): Set(Element);
body: ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

(2) using postconditions (note the use of the reserved word 'result' following the 'post:' prefix):

context Element::allOwnedElements(): Set(Element);
post: result = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

(3) using auxilliary definitions (note the 'def:' prefix in the second line):

context Element
def: allOwnedElements(): Set(Element) = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

Unfortunately, neither of the two forms used in the spec conform to any of these formats, which seems to imply that every single query operation in the spec that is defined in OCL is invalid! There are 73 such queries at the moment.

Can someone from the OCL team shed light on this?

Composite structures/Unspecified connector features between ports having multiple interfaces. What happens when ports have multiple interfaces, that in addition can mix
required and provided interfaces? This is not specified. In particular, a
connector could connect two ports using only a specified subset of the
interfaces from both ports.

Recommendation:
Extend the metamodel to allow the specification of the interfaces used for a
connector between ports having several interfaces.

or

Provide a default rule for that situation, such as the connector uses the
compatible interfaces between the interfaces of both ports.

p. 386, it is written: "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line". Figure 8-144 p. 372 presents several sizes of grey rectangles. Particularly, does it mean that method activation is performed all along the Lifeline ob1:C1? A temporal vertical axis will be added to allow several sizes of rectangles and duration of method activation.

In the UML 2 Interaction package specification (UML
2 spec, dated 2003/04/10): p. 381, it is written that
"InteractionFragment is an abstract notion of the most general
interaction unit. An interaction fragment is a piece of an interaction.
Each interaction fragment is conceptually like an interaction by itself".

InteractionFragment is described as an abstract notion and Interaction
is defined as a specialization of InteractionFragment. Don't we define
normally in the other way around: the InteractionFragment is the
abstract notion and is called Interaction and the interaction is called
InteractionFragment? We can have the definition for Interaction
(previously called InteractionFragment): "Interaction is an abstract
notion of the most general interaction unit. An Interaction is composed
of at least an InteractionFragment".

Usual semantics for fragments refers to something within something else
but here, the something else is undefined.

It is possible to represent local attributes to an Interaction (see Figure 8-148 p. 380) but it is not written how these attributes are treated: are they public to all the lifelines? Is it possible to have private attributes and in this case to which lifelines? Are they local to the Interaction? What happens if one of the lifeline is self? Does it mean that these parameters are owned by the self lifeline?

Is it not possible to have a symbol for the setting? That could help reading the diagram.

Lifelines are associated to Interaction but it is not possible to save the ordering contrary to the fragments.

It is not possible to represent that an Interaction frame represents a design pattern with unbound parameters

Please accept the following as an Issue for the UML 2 FTF.

State Machine Package--Compliance

Compliance with the state machine package is too onerous for
many vendors.

There is no need-for many of us-to include choice points, entry
points, and other elements.

An suggested layering would consist of:
Layer 1: Initial pseudo states, states, final states, events, transitions.
Layer 2: Stuff required to support hierarchy
Layer 3: Stuff required to support orthogonal regions.
Layer 4: All the rest.

Discussion
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

If we take Activity as fundamental, and consider that we can't specify something that happens with Action alone, shouldn't we remove the first sentence of the second paragraph of 11 Actions : 11.1 Overview : Basic Concepts:

"An action is the fundamental unit of behavior specification."

Discussion
An action is fundamental in that the behavior of an Activity is built up from Actions. An Activity does
not have any behavior on its own. Actions can also be used to specify behavior within the context of an
Interaction.
Disposition: Closed - No Change

We read as a constraint for connector (composite structure)

[2] If a connector is attached to a connectable element which has required
interfaces, then the connectable elements attached
to the other ends must realize interfaces that are compatible with these
required interfaces.

And Commponents::Connector provides the following constraint:
[1] A delegation connector must only be defined between used Interfaces or
Ports of the same kind, e.g. between two provided
Ports or between two required Ports.

Both are in contradiction.

Proposed correction:

Ditch CompositeStructure::Connector constraint [2]

Discussion
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

03-08-02 Figure 63 - firstly there ar a couple of typoes. The interface
stereotype on IAlarm is missing <<, and sensor should be ISensor. More
serious are the implications of the caption - "IAlarm is the required
interface for any classifier implementing Isensor;
conversely, Isensor is the required interface for any classifier
implementing
IAlarm."

To me the caption sounds wrong but at the very least more explanation is
needed. Firstly, does having the association to the interface imply that a
usage dependency is required to ISensor from any class that implements
IAlarm? If so a constraint is needed to enforce that. Secondly, isn't such a
usage dependency redundant, given that its existence is implied from the
presence of the association?

Discussion
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

It is not possible to represent atomic message sending

Discussion
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

It is possible that the sendEvent and the ReceiveEvent are on the same Lifeline but it is not possible to specify whether the sender will receive a copy of the Message.

Discussion
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The signature of the Message class is said to be of type NamedElement but such class allows for instance to write the qualifiedName and the visibility (see p. 11) and we do not know exactly what these two features offer here.

Discussion
UML 2.5 message notation was clarified considerably.
Disposition: Closed - No Change

It is not possible to write which InteractionFragment is addressed with a formal Gate

Discussion
Already addressed by clarification of gate matching rules in UML 2.5
Disposition: Closed - No Change

"[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema," [2] but there is no XMI schema. "It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architectually align and finalize the relevant specifications." [Appendix F] That is consistent with the OMG Document Archives, which show: ad/03-04-02: XMI for U2 Partners' UML 2.0: Superstructure, 3rd. revision (Contact: Mr. Cris Kobryn) No description of this document is available. Formats: Note: Not yet available. An XMI schema should be supplied, or the requirement to comply with an XMI schema should be removed.

No Data Available

Behaviors: objects that don't exist?

At 13.1 we read:

"Behaviors, as such, do not exist on their own, and they do not communicate. ... (Note that an executing behavior may itself be an object, however.)"

It is not clear what this is intended to mean. To the untutored reader it seems to be a contradiction.

What a behavior is and what a behavior execution is is fundamental to this half of UML. Whatever is intended should be spelled out clearly for the reader, very clearly.

see above

Issue 6090 correction. The following sentence should have been added to the last paragraph of the resolution to issue 6090: "An action may not put more values on an output pin in a single execution than the upper multiplicity of the pin."

see above

"[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema." [2] The requirement to comply with an XMI schema may be ambiguous. If this is intended to require that a compliant implementation correctly create a model from an XMI file written according the the XMI scheam and write an XMI file from a model according to that schema, this ought to be spelled out.

This aspect has been clarified as part of the resolution to issue 6248

Issue 6094 correction. The resolution to Issue 6094 made action concrete, but left the assocations input and output as unions, which are derived and cannot be used in a a direct instance of Action (the input and output associations were changed to nonderived, but this is inconsistent). Restore original model and introduce OpaqueAction instead

see above

At present, a lifeline always requires a corresponding ConnectableElement. For informal users of UML this requires that have to declare a specific structure for every interaction diagram that they want to draw. However, there are many uses of UML who want a less formal approach. For example, people may want to attach scenarios to use cases informally, that is, without having to talk about any specific connectable elements.

Therefore, the multiplicity of the Lifeline::represents association end should be changed from 1 to 0..1.

see above

The drawings show property strings on association ends, which consist of a comma separated list of property strings. This is not authorized by the Notation section of 7.11.2.

No Data Available

A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value of one or more attributes or associations." [13.3.8] Does this intend to mean a change in value not of of one or more attributes, but of one or more slots? If so, then does it also intend to mean a change in value not of of one or more associations, but of one or more links? But, can the value of a link change? "A link is a tuple with one value for each end of the assocaition, where each value is an instance of the type of the end." [7.11.2] With a different value, we have a different tuple. Perhaps the text intends: A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value in one or more slots or the creation of destruction of one or more links.

see above

The metamodel for RAS Profile omits most of the aspects included in the
specification of the specific profiles contained in the specification:
for example the Profile from which it is derived, the list of classes
and attributes (required or optional) and constraints.

No Data Available

It's not at all clear how to use RAS to reference UML (or other) models
which might represent the design of a component, or might be reusable
assets in their own right - despite the fact that the Model may be in
the same repository as the RAS Asset definition!
The description of Artifact (in Section 2.4.10.1 of the RFC) clearly
implies that an Artifact must be (or refer to) a file: while it would be
possible to export a Model as a XMI file and reference it, this
dramatically reduces the possibility of proper management, editing and
impact analysis of the modeling elements, and should only be required
for physical interchange purposes. In fact requiring models to be
instantiated in XMI files ironically works against the reuse of the
model elements (e.g. common classes reused in the design of multiple
components).
The RAS Profile mechanism seems to require the construction of new
RAS-specific metamodels and does not seem readily to allow the re-use of
existing metamodels, models and tools such as UML.
For example, a more sensible approach for support of John Cheesman's
Component book would be to use a UML Profile (as indeed he does in the
book!) and allow the top level package to be linked to the Asset.
Similarly the UML Diagram Interchange standard already has a metamodel
for Diagrams (linked to model elements) so why create another
representation here?

Proposed resolution:
Allow artifacts to reference arbitrary model elements (this can be
achieved through an association to Reflective::Object which is the
implicit superclass of every class in a MOF 2 metamodel).
Allow a RAS Profile to refer to a Package (representing a metamodel or
UML Profile) rather than having to create its own metamodel.

No Data Available

These provide an unwarranted overhead to classifying objects both in
terms of storage and processing: for example rather than just adding a
Descriptor to an Asset's Classification, one has first to check if there
is an appropriate DescriptorGroup and add it or link to it. Similarly
when removing a Descriptor one needs to check if the DescriptorGroup is
now empty and then remove it. This is very tricky if one is performing
the update via XMI import.
Moreover there is redundancy and the possibility of inconsistency with
the DescriptorGroup referring to a Context and its contained Descriptors
also referencing a Context.

Proposed resolution:
Delete DescriptorGroup.
Link Descriptor directly to Classification.
Move the 'reference' property from DescriptorGroup to Descriptor: this
adds a bit of overhead to each Descriptor but on the other hand provides
more power in allowing a proper definition of the specific Descriptor to
be referenced. This reference also allows the Descriptors to be grouped
in practice (e.g. for display purposes).

No Data Available

Though it is useful to have the flexibility of referring to external
schemas, it leaves no standard means of defining the schemas: RAS should
re-introduce the metamodel for Classification Schemas that was in RAS
1.x, allowing for the definition of Free-form or Enumeration
Descriptors. Additionally it should be possible to define the nodes for
an Enumeration Descriptor as 'exclusive' (allowing an asset to have only
one from the set), and there should be a proper containment mechanism
(so that when the schema is deleted all its nodes etc are also deleted).

No Data Available

Associated Profile Issue:

I expected to find the GUID ID for the Defaultcomponentprofile and the
Defaultwebserviceprofile in the respective xsd files. However, I don't
find any ID or reference to an ID

Associated xsd's:

There is an error when I try to load "Defaultcomponentprofile.xsd" as
shown below. It is possible that I don't have the lastest version of the
file.

Associated xsd's:

There is an error when I try to load "Defaultwebserviceprofile.xsd" as
shown below. It is possible that I don't have the lastest version of the
file.

Default Profile Change Request: Activity Parameters

Table of Contents
1. Introduction 4

2. References 4

3. Design Requirements 4

4. Design Constraints 4

5. Issues 4

5.1 Specifying parameters for an Activity is very difficult 4
5.1.1 Description 4

6. Considered Approaches 4

6.1 Preferred Approach - Add class ActivityParameter to the metamodel 4
6.1.1 Description 4
6.1.2 Pros 5
6.1.3 Cons 5
6.2 Alternate Approach 1 – Include the Parameters in an Activity attribute 5
6.2.1 Description 5
6.2.2 Pros 5
6.2.3 Cons 5
6.3 Alternate Approach 2 – Expand the class VariabilityPointBinding 5
6.3.1 Description 5
6.3.2 Pros 6
6.3.3 Cons 6

7. Design Artifacts 6

7.1 Figure 1 6
7.2 Figure 2 7
7.3 Figure 3 7
7.4 Example 1 8

8. Future Considerations 9

9. Draft Reviews Threads 9

1. Introduction

This document describes the issues the RAS Aurora Program development team has experienced while trying to write tooling to effectively exploit the activity element in the RAS default profile. It also contains a proposal to help alleviate these issues.

2. References
· Reusable Asset Specification(04-06-06.pdf)

3. Design Requirements
· Provide a mechanism to easily associate parameters with an activity
· Concretely define the relationship between activities and their parameters at the metamodel level
4. Design Constraints
· Require only minor changes to the current default profile metamodel
5. Issues

5.1 Specifying parameters for an Activity is very difficult
5.1.1 Description

It’s quite common to include asset or artifact activities in a RAS manifest that are interrogated by clients during some part of the asset’s lifecycle. Often the activity requires additional pieces of information that’s used by the client to help execute the activity in one manner or another during processing. For example, IBM’s Eclipse based RAS implementation provides an activity to build a deployable project that’s processed during asset packaging. The RAS manifest author has the option to build that project with or without source and package the binaries in different formats. In today’s default profile metamodel, there doesn’t appear to be a clear, simple way to specify the options. Ideally the metamodel should provide a way to express the parameters for an activity in an unambiguous way. Below are a few approaches we considered including a preferred approach to resolving this issue. We are open to other suggestions as well.

6. Considered Approaches
6.1 Preferred Approach - Add class ActivityParameter to the metamodel

6.1.1 Description
Our preferred approach is to add a new class called ActivityParameter to the metamodel for the default profile that extends the class Descriptor. This new class would contain one attribute named defaultValue that would provide the ability to specify for the parameter exactly what the name implies…a default value. The name and value attributes inherited from the Descriptor class would provide the mechanism for defining the parameters and their values. See Figure 1 and Example 1.

6.1.2 Pros

· Concretely defines the relationship between activities and their parameters in a clear, straight forward manner.
· Client will not have to interrogate the attributes of other elements to try to determine if they are the parameters for activity.
· The parameters will not have to be included in one of the attributes of the activity.

6.1.3 Cons

· New class and relationships must be added to the metamodel

6.2 Alternate Approach 1 – Include the Parameters in an Activity attribute

6.2.1 Description
Include the parameters as part of one of the existing activity attributes. Use special characters to denote the parameters and their values so that they can be specified and accessed by clients.

6.2.2 Pros

· Requires no changes to the current default profile metamodel

6.2.3 Cons

· No clear relationship between the activity and the parameters
· Adds confusing extraneous information to activity attributes that doesn’t apply to the attribute.
· Clients must know which attribute contains the parameters and how to specify/access them

6.3 Alternate Approach 2 – Expand the class VariabilityPointBinding

6.3.1 Description
Add a new attribute to the class VariabilityPointBinding. This will provide a way to associate the parameters with the activity using an existing metamodel relationship. See Figure 2 or Figure 3..

6.3.2 Pros

· Requires no new classes to be added to the metamodel
· Provides a mechanism to associate parameters to an activity through an existing relationship.

6.3.3 Cons

· No clear relationship between the activity and the parameters. The binding rules will have to be interrogated to find a particular binding rule and then process it.
· Using the VariabilityPointBinding class for this purpose doesn’t really seem like what the intended purpose is according to the RAS spec. It’s tied to a VariabilityPoint which doesn’t necessarily apply.
· A new attribute must be added to the VariabilityPointBinding class.

7. Design Artifacts

7.1 Figure 1

7.2 Figure 2

7.3 Figure 3

7.4 Example 1

An example expansion of the XML in a RAS manifest for an activity with parameters for the preferred solution:

<artifactActivity artifact="//@solution/@artifact.0">
<activity task="Build Deployable Project" role="com.ibm.xtools.ras.export" taskType="com.ibm.xtools.ras.BuildDeployableProject">
<activityParameter name="includeSource" value="true" defaultValue="false" />
</activity>
</artifactActivity>

Thanks,
Grant

-----------------------------------------------------------
Grant Larsen
STSM
IBM Rational software
Voice: (303) 932-7368
Mobile: (303) 601-1257
Fax: (303) 932-6963
Notes: Grant J Larsen/Denver/IBM
E-mail: gjlarsen@us.ibm.com

RAS FTF add support for Activi.gif
RAS FTF add support for Activi1.gif
RAS FTF add support for Activi2.gif

No Data Available

Need to add a chapter to the specification document which describes techniques for doing extensions to RAS profiles. There are two major sections to this chapter to consider initially; first, describe how to create Rose models to extend the RAS profile using the MOF modeling conventions and second, describe the creation of the genmodel/ecore EMF files from which the RAS XSD file and Java API are produced.

No Data Available

Convert every place in all profiles that used a string attribute representing a description to be a reference to a Description class/element.

Elements affected:
Condition
InterfaceSpec(Component profile)
Operation
RelatedAsset
VariabilityPoint

No Data Available

Convert every place that used a string reference representing an artifact to be an actual reference to the Artifact class/element in the Solution class/element.

Pros:
Providing the ability to include a lot more information about that artifact than simply how to locate it using the reference. You now have an actual Artifact element that can be interrogated for information.
Allows us to apply the Visitor pattern to our Java implementation making it incredibly easy and flexible for a client to visit the artifacts in the asset independent of where they are located or how they are structured. Third parties can also tie into this so that we visit all their artifacts in custom profiles as well.

Cons:
This opens up the possibility of additional broken references if someone deletes the artifact that a given element was referring to.

Classes/Elements affected:
ArtifactActivity
DescriptorGroup
Profile
RelatedAsset
RelatedProfile
Usage
VariabilityPoint

No Data Available

Section 7.7.5 of the spec related to the RAS webservice profile indicates that there is still a relationship between RAS component and RAS webservice profiles.

"Only the new elements for this profile are outlined here. For information on other elements refer to this profile's ancestry, namely the Default Component profile and the Default profile."

This is no longer true...but more importantly however...is the fact that the current webservice profile ID still includes the component's profile ID in it's parent chain. The text in the spec needs to be updated remove association and the id history for the webservice profile needs to be updated to remove the connection to the component profile.

We propose to update the Profile.id-history attribute as follows.

Current webservice profile id-history:
F1C842AD-CE85-4261-ACA7-178C457018A1::31E5BFBF-B16E-4253-8037-98D70D07F35F::1025A790-78D4-4f57-94CE-E65B23275FCD::710CA9C5-CA9C-4be2-BB1A-D23677C62A4C

Revised webservice profile id-history, after removing the Component profile id from the id-history:
F1C842AD-CE85-4261-ACA7-178C457018A1::31E5BFBF-B16E-4253-8037-98D70D07F35F:: 710CA9C5-CA9C-4be2-BB1A-D23677C62A4C

No Data Available

The RAS2.1_defaultprofile_target_MOFXMIXMLSchema.mdl doesn't have an id attribute for the Asset element. The text of the spec clearly indicates that it should exist...

"This Asset instance defines the identity of the reusable software asset (see Asset Identity section). This Asset instance contains two required attributes; name and id. For the XMI XML schema the id does not appear in the model as it relies on the XMI generator to produce it."

We think what happened is that when all the other old id attributes were removed when preparing the MOF/XMI version of RAS...this one was also accidentally removed. This needs to be added back into the model.

Elements affected:
Asset

No Data Available

Para 2 of 2.4.6 in RFC states that "the id attribute is expected to
contain a globally unique identifier": the meaning and scope of
'globally' should be clarified.
In particular, since later in the section when discussing the 'version'
attribute it is implied that 2 versions of the 'same' asset may have the
same id.
References to use of XMI for generating id are certainly not correct
since xmi:ids are unique only within the scope if a single XMI file, and
may differ for the same element in different files.

No Data Available

P20 of RFC states "The actual filename may vary for the profile file,
but the XML instance documents must reference the schema file." (and
refers to xsi:schemaLocation) This is out of step with common practice
for XML: surely the only thing required is the URI of the Schema via
xmlns.

No Data Available

In the conformance clause, for each conformance point provide cross reference to normative clauses that must be implemented in order to satisfy the conformance point

No Data Available

The Japan EJB Consortium would like to add a RAS EJB Component profile as an example extension in the Appendix of the RAS "final" report.

No Data Available

At the moment dependencyType is just a string associated with
ArtifactDependency (in 2.4.10.1 of RFC): this provides no control or
impact analysis or consistency. DependencyKind (better name for
consistency with other specifications) should be an element in its own
right, and it should be possible to associate it with a Profile (e.g..
the Component Profile will introduce new types of Dependency).

No Data Available

The Http Request / Response Description section should be updated with services interfaces that have been discovered/refined from tooling efforts since the original RAS submission.

No Data Available

The Java API Description section (5.2) should be removed from the RAS document. The Http Request / Response Description should be preserved and should represent the interface to the RAS repository

No Data Available

Associated Profiles:

In all of the profiles, the association order and property order shown in
the annotations does not match the order shown in each element. For
example, in the Defaultprofile, the Asset Element order shown is
classification, solution, usage, related asset, profile and description
while the order listed in the annotation is profile, description,
classification, solution, usage and related asset.

No Data Available

Default Profile Issue:

The RAS specification states that for profile histories the new profile’s
ID is prepended to the previous ID/history. It appears that this is
backwards in the default profile. Either the RAS specification or the
Defaultprofile needs to be corrected.

No Data Available

The statement in 2.3 1 of RFC "it is up to any tool or the user to
determine which files in the package are manifest files and which are
artifacts of the asset." is unacceptable for interchange purposes

No Data Available

Constraint 13 in section 2.4.14 of RFC "Tool vendors must provide
processing for at least one primary artifact type." should be a
compliance point not a constraint on the metamodel.

No Data Available

The current structure of DescriptorGroup and Descriptor provides for only one level in the scheme for classifying assets. The DescriptorGroup and Descriptor classes should be updated to allow nesting of these classes. This allows for simple classification schemes to be represented in the asset manifest files.

No Data Available

There are several places in the RFC document which alters the order of the concatenated ids for the profiles in the id-history attribute.

The document needs to be consistent; the order is:

grandfather profile_id::father profile_id::child profile_id

It goes from least derived on the left to most derived on the right.

No Data Available

The RAS documents need to be updated to reflect version 2.2 for the final specification

No Data Available

The original RAS XML schema used id attributes as a way to create associations amongst elements. However, the MOF/XMI version of XML schema removes this requirement and allows for associations amongst elements. Several constraints in section 7.4.14 are affected by this.
Constraint 4: The context-id attribute in the <artifact-context>, <descriptor>, <artifact-dependency>, <variability-point>, <context-ref> and <artifact-activity> element must specify an id from a context element found in the same manifest document.
Constraint 5: The artifact-id attribute in the <artifact-activity>, and <artifact-dependency> elements must specify an id from an <artifact> element found in the same manifest document.
Constraint 6: The variability-point-id attribute of the <variability-point-binding> element must specify an id from a <variability-point> element found in the same manifest document.
Constraint 11: The artifact-id attribute on an <artifact-dependency> element and <artifact-activity> element must use an id from an <artifact> element in the same document.

We propose to update the text for these constraints to say that element "X" should reference another element, "Y", in the same document.

No Data Available

The RAS document needs to be updated with a section describing profile extension in a non-vendor specific manner. Vendor-specific extensions should not be included in the RAS document.

Per the voting in the affirmative on issue 8211 this issue is being submitted.

No Data Available

On items such as “value” attributes on classes there is not a direct translation from the Rose model thru the EMF translators. There is no way to map the text element in the XML form to the Rose model elements. We need to describe the manual steps to create the XML schema from the Rose model.

No Data Available

Currently the RelatedAsset class/element only contains the id of the related asset. This is fine if the related asset relationship type is aggregation because the related asset has a reference to the actual artifact that represents the asset. We need to support loosely coupled asset relationships where you don't have a direct reference to the related asset but instead some rules of where to search for it. In this scenario, we need more information to uniquely identify the asset. Specifically...we need the version of the related asset. We'd like to add an assetVersion attribute to the RelatedAsset element to match the assetId attribute that already exists. We think this provide us the information we would need for this loose coupling.

No Data Available

In section 8.1 Mapping RAS to .ras files, it indicates that the RAS asset should include the .xsd file for the profile...

"Each .ras file includes the following types of files:
• one XML Schema file (e.g., RASProfile.xsd )
• one manifest file (e.g., rasset.xml)
• one or more artifact files (e.g., source code, models, test scripts, and so on)"

We no longer include the .xsd file(s) in our packaged assets like XDE did. If we do...it will be potentially more than one based on the profile being used. We either need to start including this in today's RAS implementation or remove this from the spec. I'm also pretty sure our .rmd files would not always validate in all circumstances against the minimum constraints the spec indicates the .xsd would enforce. Not positive on this yet though...need to investigate some more.

Proposal:
In section 8.1, change text to:
zero or more XML Schema files (e.g., RASProfile.xsd )

No Data Available

On page 49 of the RAS document it states

Constraint 1: The manifest file must validate against the XML Schema associated with the profile and must be referenced by the manifest file.

We propose that this should be changed to:

Constraint 1: The manifest file must validate against the XML Schema associated with the profile.

No Data Available

Please add these two people that have contributed significantly to the RAS since the original submission, namely Neil Boyette (IBM), Don Weinand (IBM).

No Data Available