Reusable Asset Avatar
  1. OMG Specification

Reusable Asset — Closed Issues

  • Acronym: RAS
  • Issues Count: 68
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UML25-574 State Machine Package--Compliance RAS 2.0b1 UML 2.5 Resolved closed
UML25-573 Actions need to be independent from Activities RAS 2.0b1 UML 2.5 Resolved closed
UML25-566 Composite structures/contradictory constraint on connector RAS 2.0b1 UML 2.5 Resolved closed
UML25-568 UML 2 Super/Interfaces RAS 2.0b1 UML 2.5 Resolved closed
UML25-571 Issue in UML 2 CombinedFragment class RAS 2.0b1 UML 2.5 Resolved closed
UML25-570 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-569 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-572 Issue in UML 2 Gate class RAS 2.0b1 UML 2.5 Resolved closed
UML23-144 Section: Classes RAS 2.2 UML 2.3 Resolved closed
UML22-987 p. 732: Show examples of new stereotype notation RAS 2.2 UML 2.1 Resolved closed
UML22-986 p. 732: Change example to be consistent with new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-983 Make instance model consistent with new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-982 p. 729: Extend the Clock example to show metaclass property RAS 2.2 UML 2.1 Resolved closed
UML22-985 p. 731: Make example consistent with new definition of Clock. RAS 2.2 UML 2.1 Resolved closed
UML22-984 p. 731: Make this example consistent with the new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-988 pp. 733-734: Add association as valid graphic path RAS 2.2 UML 2.1 Resolved closed
UML22-991 TimeExpression RAS 2.2 UML 2.1 Resolved closed
UML22-992 abstract Action in Activity diagram RAS 2.2 UML 2.1 Resolved closed
UML22-981 p. 728: New presentation options. Replace the following paragraph RAS 2.2 UML 2.1 Resolved closed
UML22-980 p. 721: Allow stereotypes to have properties that are typed by metaclasses RAS 2.2 UML 2.1 Resolved closed
UML22-968 Can't specify mutator semantics for derived properties RAS 2.2 UML 2.1 Resolved closed
UML22-967 Section: 12.3.37 RAS 2.2 UML 2.1 Resolved closed
UML22-976 MessageEnd RAS 2.2 UML 2.1 Resolved closed
UML22-978 Incorrect Communication Domain Model RAS 2.2 UML 2.1 Resolved closed
UML22-977 Obsolete term EventOccurrence still used in multiple places RAS 2.2 UML 2.1 Resolved closed
UML22-972 Notation of Attributes and Associations subsections RAS 2.2 UML 2.1.2 Resolved closed
UML22-966 OpaqueAction RAS 2.2 UML 2.1 Resolved closed
UML22-941 Profile Semantics, pag 723 RAS 2.2 UML 2.1 Resolved closed
UML22-940 policy to describe the Associations sub section of a meta class description RAS 2.2 UML 2.1 Resolved closed
UML22-542 XMI schema RAS 2.0b1 UML 2.1 Resolved closed
UML14-559 UML 2 issue, Common Behaviors RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-553 Issue 6090 correction RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-548 XMI schema (02) RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-552 Issue 6094 correction. RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-551 UML 2 Super/Interactions/Need unattached lifelines RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-550 property strings on association ends RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-549 change trigger RAS 2.0b1 UML 1.4.2 Resolved closed
RAS22-10 Incomplete metamodel for RAS Profile RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-9 Allow Models to be referenced from Assets and avoid duplicating UML RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-8 Remove Descriptor Groups RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-7 Reintroduce metamodel for Classification Schemas RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-19 RAS FTF: add support for Activity Parameters RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-18 RAS FTF: add chapter to describe RAS profile extension RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-27 string attribute for description with reference to Description class RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-26 replace string artifact reference with artifact reference RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-29 webservice profile incorrect connection with component profile RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-28 missing Asset id attribute RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-14 Lack of clarity of 'globally unique' for ids RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-13 Unnecessary requirement to reference the physical schema file RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-17 RAS FTF issue --conformance clause RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-16 a RAS EJB Component profile RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-15 Make DependencyType an element in its own right RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-23 RAS FTF: update the Http Request / Response Description section RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-22 RAS FTF: remove the Java API Descriptions section RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-21 Issue with RAS ptc/04-06-06 Element Order in profiles RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-20 Issue with RAS ptc/04-06-06 ID History in Defaultprofile RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-12 Provide standard means of identifying manifests RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-11 Constraint 13 should be a compliance point RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-25 RAS FTF: nesting DescriptorGroup and Descriptor RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-24 RAS FTF: order of id-history inconsistent RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-37 RAS FTF: RAS docs need version number updated RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-36 RAS FTF: improper use reference to id attributes for element relationships RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-33 create a chapter or section in RAS document describing profile extension RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-32 add text to spec/appendix describing translation of submitted Rose models RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-31 add assetVersion attribute to RelatedAsset RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-30 refine constraint to include .xsd file in .ras file RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-35 RAS FTF: manifest file must reference XML schema RAS 2.0b1 RAS 2.2 Resolved closed
RAS22-34 add two people to 6.3 acknowledgements section in the RAS doc RAS 2.0b1 RAS 2.2 Resolved closed

Issues Descriptions

State Machine Package--Compliance

  • Key: UML25-574
  • Legacy Issue Number: 7555
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Actions need to be independent from Activities

  • Key: UML25-573
  • Legacy Issue Number: 7552
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    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."

  • Reported: RAS 2.0b1 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Composite structures/contradictory constraint on connector

  • Key: UML25-566
  • Legacy Issue Number: 7431
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    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]

  • Reported: RAS 2.0b1 — Wed, 2 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2 Super/Interfaces

  • Key: UML25-568
  • Legacy Issue Number: 7441
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    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?

  • Reported: RAS 2.0b1 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Issue in UML 2 CombinedFragment class

  • Key: UML25-571
  • Legacy Issue Number: 7450
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to represent atomic message sending

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Issue in UML 2 Message class

  • Key: UML25-570
  • Legacy Issue Number: 7449
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Issue in UML 2 Message class

  • Key: UML25-569
  • Legacy Issue Number: 7448
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Issue in UML 2 Gate class

  • Key: UML25-572
  • Legacy Issue Number: 7452
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

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

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: Classes

  • Key: UML23-144
  • Legacy Issue Number: 8768
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for navigable ends owned by an association. Figure 21 should include a notation for navigable ends owned by the association

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This was effectively resolved by the introduction of the "dot" notation in UML 2.1 for ends owned by end types.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 732: Show examples of new stereotype notation

  • Key: UML22-987
  • Legacy Issue Number: 8852
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    8) p. 732: Show examples of new stereotype notation. Add the following including new Figure 463:
    "Finally, the two alternate notational forms are shown.

    • Other notational forms for showing values
      AlarmClock is valid for OS version 1.1, is POSIX-compliant and it has a starting operation called Start. The compartment form of notation is shown on the left and the in-symbol form on the right (note that not all properties of Clock are shown on the right."
  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 468 - 469 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 732: Change example to be consistent with new definition of Clock

  • Key: UML22-986
  • Legacy Issue Number: 8851
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    7) p. 732: Change example to be consistent with new definition of Clock. Replace figure 462 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 466 -467 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make instance model consistent with new definition of Clock

  • Key: UML22-983
  • Legacy Issue Number: 8848
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    4) p. 730: Make instance model consistent with new definition of Clock. Replace Figure 458 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 463 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 729: Extend the Clock example to show metaclass property

  • Key: UML22-982
  • Legacy Issue Number: 8847
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)3) p. 729: Extend the Clock example to show metaclass property and the use of Boolean. Replace Figure 456 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 462 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 731: Make example consistent with new definition of Clock.

  • Key: UML22-985
  • Legacy Issue Number: 8850
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    6) p. 731: Make example consistent with new definition of Clock. Replace Figure 461 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8849 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 731: Make this example consistent with the new definition of Clock

  • Key: UML22-984
  • Legacy Issue Number: 8849
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    5) p. 731: Make this example consistent with the new definition of Clock. Replace Figure 459 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 464 - 465 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

pp. 733-734: Add association as valid graphic path

  • Key: UML22-988
  • Legacy Issue Number: 8853
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    9) pp. 733-734: Add association as valid graphic path. Add the following row to Table 24:

    Unidirectional Association See "Profile (from Profiles)" on page 720

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeExpression

  • Key: UML22-991
  • Legacy Issue Number: 8894
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    TimeExpression should hold time value, but there is no attribute for that. Maybe TimeExpression should be inherited from OpaqueExpression and hold value in "body"?

  • Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 472 - 478 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

abstract Action in Activity diagram

  • Key: UML22-992
  • Legacy Issue Number: 8896
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    4. The same situation is with abstract Action in Activity diagram. OpaqueAction also can't be used, because can't have Pins.
    How to draw "human friendly" action (activity)? The only way is to use CallBehaviorAction?

  • Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8867 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 728: New presentation options. Replace the following paragraph

  • Key: UML22-981
  • Legacy Issue Number: 8846
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    2) p. 728: New presentation options. Replace the following paragraph:
    "The values of a stereotype that has been applied to a model element can be shown as part of a comment symbol tied to the model element. The values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown."
    with the following text:
    "The values of a stereotype that has been applied to a model element can be shown in one of three ways:
    ·As part of a comment symbol tied to the symbol representing the model element
    ·In compartments of a graphic node representing the model element.
    ·Above the name string within a graphic node or before the name string otherwise
    In the case where a compartment or comment symbol is used, the user may elect to show the stereotype name in guillemets before the name string in addition to in the compartment or comment.
    They are displayed as name/value pairs, thus:
    <namestring>'='<valuestring>
    If a stereotype property is multi-valued then the valuestring is displayed as a comma-separated list:
    <valuestring>::=<value>

    {','<value>}

    Certain values have special display rules:
    ·As an alternative to a name/value pair, when displaying the values of boolean properties diagrams may use the convention that if the namestring is displayed then the value is True, otherwise the value is False;
    ·If the value is the name of a NamedElement then optionally its qualifiedName can be used.
    If compartments are used to display stereotype values then an additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets. Any graphic node may have these compartments.
    Within a comment symbol, or if displayed before/above the symbols's namestring, the values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown.
    When displayed in compartments or comment symbol at most one name/value pair can appear on a single line. When displayed above/before a namestring the name/value pairs are separated by semicolons and all pairs for a given stereotype are enclosed in braces."

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 460 - 461 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 721: Allow stereotypes to have properties that are typed by metaclasses

  • Key: UML22-980
  • Legacy Issue Number: 8845
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)
    . Change paragraph 4 to:
    "As part of a profile, it is not possible to have an association between two stereotypes or from a metaclass in the reference metamodel to a stereotype, although a unidirectional association from a stereotype to a metaclass, or equivalently typing a stereotype property by a metaclass, is allowed. The effect of new (meta) associations between stereotypes can be achieved in limited ways either by:"

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7756 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can't specify mutator semantics for derived properties

  • Key: UML22-968
  • Legacy Issue Number: 8769
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    It is currently not possible to specify the effect of setting derived properties that are not read-only. As a result, derived properties are under-specified in the model because the semantics of updating them cannot be modeled or stated formally.

  • Reported: RAS 2.2 — Fri, 6 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37

  • Key: UML22-967
  • Legacy Issue Number: 8766
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It's a common modeling scenario that an object flow with an outpin pin at the source must target an action directly (without a pin). For example a decision node with an incoming object flow - the object is necessary for the guard condition -, but one or more of the target actions don't need that object. Due to the constraint that object flows don't have actions at either end I must model an input pin. For example in case of a CallOperationAction an operation with an additional parameter must be defined even if I don't use it. It's just for modeling purposes. I've assumed before reading the constraint in the specification that an object flow can target an action directly. In that case it's semantic is the same as for the control flow. That works perfect for me. I would propose to weaken the constraint for object flows that actions as targets are allowed. The object token enables the action and gets lost. Any other solution with the same semantic is also acceptable.

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MessageEnd

  • Key: UML22-976
  • Legacy Issue Number: 8784
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    MessageEnd is MessageOccurrenceSpecification that redefines "event" as MessageEvent.
    DestructionEvent and CreationEvent are not subclasses of MessageEvent, so can't be on message end, so how to map "create message" and "destroy message"?

  • Reported: RAS 2.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect Communication Domain Model

  • Key: UML22-978
  • Legacy Issue Number: 8825
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Fig. 308 does not contain the correct domain model. The current model that
    appears in Fig. 308 is a duplicate of Fig. 307.

  • Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8292 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete term EventOccurrence still used in multiple places

  • Key: UML22-977
  • Legacy Issue Number: 8824
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    1) 14.3.25 OccurrenceSpecification, the change in class name was from EventOccurrence to OccurrenceSpecification. This change needs to be noted in this document. Also, the reason why the change was made.
    2) EventOccurrence is still being use in the toBefore and toAfter association descriptions of OccurrenceSpecification.
    3) EventOccurrence is still be referenced in other areas:
    a) in the last word of the Example text on page 476,
    b) In the Notation text on Page 489,
    c) In the fifth paragraph of the overview on Page 497
    d) Multiple times on Page 509 and 510
    e) First paragraph on Page 528
    f) Multiple times on Page 531
    g) Multiple times on Fig. 347

  • Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 453 - 457 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation of Attributes and Associations subsections

  • Key: UML22-972
  • Legacy Issue Number: 8774
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation of Attributes and Associations subsections in the whole specification should be consistently follow the rules: Every entry must include * attribute/association end name * its type * its multiplicity: you should NOT omit this even if it maps to the default value of *. Also, both upper and lower multiplicities should be provided; i.e., NOT "[*]" but "[0..*]") * ALL modifiers such as subsets and redefines. When referencing other association ends, use the following convention: "<metaclass-name>::<association-end-name> (do NOT use the "." notation for this) * if something is derived, the explanation should be given how it is derived and an OCL formula might have to be provided.

  • Reported: RAS 2.2 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Most of these issues have been resolved through numerous editorial changes that were intended to ensure consistency. The exceptions are:
    „h the use of * instead of 0..* – simply not worth the effort given that the two are equivalent. It will take a lot of effort to do this with no real value; chances are that this will NEVER get done. There is no point in keeping the issue open.
    „h The derivation specification already has another open issue.
    Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueAction

  • Key: UML22-966
  • Legacy Issue Number: 8759
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    In chapter 11.3.26 OpaqueAction is described as subclass of Pin. It
    > should be subclass of Action.

    That's a bug. Please raise an issue.

    > Can OpaqueAction be used as default Action type in Activity diagrams
    > and be as replacement of old-style user defined ActionStates in UML 1.4?

    It sounds like you are asking for a new feature. I don't see that the RTF will accept this default. You can always do this woth a profile.

  • Reported: RAS 2.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Semantics, pag 723

  • Key: UML22-941
  • Legacy Issue Number: 8706
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    "A reference metamodel typically consists of metaclasses that are either
    imported or locally owned. All metaclasses that
    are extended by a profile have to be members of the same reference
    metamodel. A tool can make use of the information
    about which metaclasses are extended in different ways, for example to
    filter or hide elements when a profile is applied, ..."

    The specification must be explicit about the mechanism used to hide/filter
    reference metamodel elements. The SysML Partners are trying to do exactly
    this with SysML but it's not clear from the above paragraph or any other
    part of the Profiles section how to do it.

  • Reported: RAS 2.2 — Thu, 28 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

policy to describe the Associations sub section of a meta class description

  • Key: UML22-940
  • Legacy Issue Number: 8696
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    what is the official policy to describe the Associations sub section of a meta class description (using EBNF style):

    /?<end-name> : <associated-class-name> : <cardinality> (= <DefaultValue>)? <FeaturesList>? <tab> <Description>

    where:

    <end-name> ::= String

    <associated-class-name> ::= String

    <cardinality> ::= [<n>, <m>]

    <DefaultValue> ::= String

    <FeaturesList> ::=

    {<Features>}

    <Features> ::= <FeatureKind>} | {<FeatureKind>, <Features>

    <FeatureKind> ::= subsets <property-name> | redefined <end-name> | union | ordered | bag | sequence | readOnly | unrestricted

    <property-name> ::= String

    <n> ::= Integer

    <m> ::= Integer | * and m >= n

    <tab> is a tabulation

    ps: ? means it is optional part.

  • Reported: RAS 2.2 — Tue, 12 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema

  • Key: UML22-542
  • Legacy Issue Number: 7401
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[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.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 issue, Common Behaviors

  • Key: UML14-559
  • Legacy Issue Number: 7380
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 26 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 6090 correction

  • Key: UML14-553
  • Legacy Issue Number: 7561
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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."

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema (02)

  • Key: UML14-548
  • Legacy Issue Number: 7402
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[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.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 6094 correction.

  • Key: UML14-552
  • Legacy Issue Number: 7560
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Need unattached lifelines

  • Key: UML14-551
  • Legacy Issue Number: 7553
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 30 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property strings on association ends

  • Key: UML14-550
  • Legacy Issue Number: 7404
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

change trigger

  • Key: UML14-549
  • Legacy Issue Number: 7403
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete metamodel for RAS Profile

  • Key: RAS22-10
  • Legacy Issue Number: 7762
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow Models to be referenced from Assets and avoid duplicating UML

  • Key: RAS22-9
  • Legacy Issue Number: 7761
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove Descriptor Groups

  • Key: RAS22-8
  • Legacy Issue Number: 7760
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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).

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reintroduce metamodel for Classification Schemas

  • Key: RAS22-7
  • Legacy Issue Number: 7759
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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).

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: add support for Activity Parameters

  • Key: RAS22-19
  • Legacy Issue Number: 8212
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: add chapter to describe RAS profile extension

  • Key: RAS22-18
  • Legacy Issue Number: 8211
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

string attribute for description with reference to Description class

  • Key: RAS22-27
  • Legacy Issue Number: 8521
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

replace string artifact reference with artifact reference

  • Key: RAS22-26
  • Legacy Issue Number: 8520
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

webservice profile incorrect connection with component profile

  • Key: RAS22-29
  • Legacy Issue Number: 8523
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing Asset id attribute

  • Key: RAS22-28
  • Legacy Issue Number: 8522
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of clarity of 'globally unique' for ids

  • Key: RAS22-14
  • Legacy Issue Number: 7766
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary requirement to reference the physical schema file

  • Key: RAS22-13
  • Legacy Issue Number: 7765
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF issue --conformance clause

  • Key: RAS22-17
  • Legacy Issue Number: 7907
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    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

  • Reported: RAS 2.0b1 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

a RAS EJB Component profile

  • Key: RAS22-16
  • Legacy Issue Number: 7901
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 3 Nov 2004 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make DependencyType an element in its own right

  • Key: RAS22-15
  • Legacy Issue Number: 7767
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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).

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: update the Http Request / Response Description section

  • Key: RAS22-23
  • Legacy Issue Number: 8288
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Tue, 15 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: remove the Java API Descriptions section

  • Key: RAS22-22
  • Legacy Issue Number: 8287
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Tue, 15 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with RAS ptc/04-06-06 Element Order in profiles

  • Key: RAS22-21
  • Legacy Issue Number: 8282
  • Status: closed  
  • Source: Caterpillar ( Wayne Wulfert)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with RAS ptc/04-06-06 ID History in Defaultprofile

  • Key: RAS22-20
  • Legacy Issue Number: 8281
  • Status: closed  
  • Source: Caterpillar ( Wayne Wulfert)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide standard means of identifying manifests

  • Key: RAS22-12
  • Legacy Issue Number: 7764
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint 13 should be a compliance point

  • Key: RAS22-11
  • Legacy Issue Number: 7763
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Mon, 20 Sep 2004 04:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: nesting DescriptorGroup and Descriptor

  • Key: RAS22-25
  • Legacy Issue Number: 8290
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Tue, 15 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: order of id-history inconsistent

  • Key: RAS22-24
  • Legacy Issue Number: 8289
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Tue, 15 Feb 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: RAS docs need version number updated

  • Key: RAS22-37
  • Legacy Issue Number: 8597
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

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

  • Reported: RAS 2.0b1 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: improper use reference to id attributes for element relationships

  • Key: RAS22-36
  • Legacy Issue Number: 8566
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create a chapter or section in RAS document describing profile extension

  • Key: RAS22-33
  • Legacy Issue Number: 8563
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add text to spec/appendix describing translation of submitted Rose models

  • Key: RAS22-32
  • Legacy Issue Number: 8526
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add assetVersion attribute to RelatedAsset

  • Key: RAS22-31
  • Legacy Issue Number: 8525
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

refine constraint to include .xsd file in .ras file

  • Key: RAS22-30
  • Legacy Issue Number: 8524
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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 )

  • Reported: RAS 2.0b1 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RAS FTF: manifest file must reference XML schema

  • Key: RAS22-35
  • Legacy Issue Number: 8565
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

    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.

  • Reported: RAS 2.0b1 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add two people to 6.3 acknowledgements section in the RAS doc

  • Key: RAS22-34
  • Legacy Issue Number: 8564
  • Status: closed  
  • Source: International Business Machines ( Mr. Grant Larsen)
  • Summary:

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

  • Reported: RAS 2.0b1 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — RAS 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT