[Index] [Process] [CCB issues] [In work issues]
Export date: 2012-09-03 06:58:20
Row | Id | Category | Summary | Details | Priority | Status | Resolution | Release | Submitter | Assignee | Closer |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | 3558882![]() |
PLCS PSM Model | StateAssignmentSelect does not include DocumentDefinition | The current capability allows us to identify states for Digital and Physical document definitions but not the more general DocumentDefinition. Since DocumentDefinition is an instantiable supertype of PhysicalDocumentDefinition and DigitalDocumentDefinition I would sugesst removing these two and adding DocumentDefinition. | 4 | Pending | Accepted | R2.0 | philsp | robbod | robbod |
2 | 3558997![]() |
PLCS PSM Model | Allowable units on propertydefinition | It is possible to assign a property definition to a part with no value. This is used to make statements like .. all part should have these properties defined. For example an OEM could send a list of part numbers to a supplier to design the parts and a set of assigned property definitions that specify teh properties that are to be be provided. It should also be possible to specify the allowable units that are to be used for the properties. This is available in AP242. Add allowedUnits property to ExternalPropertyDefinition | 5 | Pending | Accepted | R2.0 | robbod | robbod | robbod |
1 | 3512391![]() |
PLCS PSM XSD | References type tns:Reference cannot infer legal reference | It is not possible to know from the XSD where the reference is allowed to point to. E.g. <AssignedContract uidRef="idContract"/> The uidRef="idContract" could be anything. | 5 | Open | None | robbod | mikeward | nobody | |
2 | 3540414![]() |
PLCS PSM XSD | Check config files | The XSL that generates the XSD should check that all the relationships and assignments are listed in the config file | 5 | Open | None | robbod | robbod | nobody | |
3 | 3511960![]() |
PLCS PSM Model | Optional Identifications everywhere in the PSM? | All (except Organization) ENTITY having the identifications attribute have been defined with OPTIONAL SET OF Identification. While this might be true for all Relationship/Assignment Object, this can't be correct for other object like Product / ProductVersion / Activity / ActivityMethod / etc ... Why not mandating at least 1 identification for all of these objects directly in the PSM? | 5 | Open | None | phoubaux | philsp | nobody | |
4 | 3514619![]() |
PLCS PSM Model | Errors in model definitions | The class_definitions.xml file must conform to the schema and all definitions should be complete | 5 | Open | None | robbod | steve_yates | nobody | |
5 | 3522500![]() |
PLCS PSM Model | Express WHERE rules | The PSM has none of the WHERE rules that we in the ARM. Some of these are useful, such as those on relationship preventing a relationship relating the same thing ENTITY Alternate_product_relationship; name : OPTIONAL STRING; description : OPTIONAL STRING; alternate_product : Product; base_product : Product; criteria : OPTIONAL STRING; UNIQUE UR1: alternate_product, base_product; WHERE WR1: alternate_product :<>: base_product; WR2: EXISTS(criteria) OR (TYPEOF(SELF\Alternate_product_relationship) <> TYPEOF(SELF)); END_ENTITY; | 5 | Open | None | robbod | philsp | nobody | |
6 | 3524259![]() |
PLCS PSM Model | IdentifcationContext - add more than Organization | Right now Organization is the only context allowed for an identification. We should add project, product, document, into the select. That way we can - identify notes in the context of a drawing. - treat a project as the context | 5 | Open | None | robbod | nobody | nobody | |
7 | 3528773![]() |
PLCS PSM Model | Add uniqueness constraints | There are a number of blocks that should have uniqueness constraints added. These should be determined by the dexlib templates, the ap239ed2 model. E.g. NumericalContext ExternalAnalysisModel | 5 | Open | None | robbod | nobody | nobody | |
8 | 3530041![]() |
PLCS PSM Model | ExchangeContextClassLibrary limit to one per file | There should a rule stating that there is one an only one ExchangeContextClassLibrary in an exchange file | 5 | Open | None | robbod | nobody | nobody | |
9 | 3530047![]() |
PLCS PSM Model | Should PLCS have: PartVersionRelationship | Should PLCS have: ENTITY PartVersionRelationship SUBTYPE OF (ProductVersionRelationship); SELF\ProductVersionRelationship.relating : PartVersion; SELF\ProductVersionRelationship.related : PartVersion; END_ENTITY; There is already a SystemVersionRelationship | 5 | Open | None | robbod | nobody | nobody | |
10 | 3530552![]() |
PLCS PSM Model | Breakdown reuse | At present a breakdown structure can be applied to more that one product via productOf the realization of the elements is done via BreakdownElementRealization however these two relationships are not related. This means that I can have a simple breakdown of an aircraft say into elements fuselage, port wing and starboard wing. This could be applied to both an A380 and a 1:100 scale model A380. I can have port wing realised by a wing many metres long and a port wing realized by the model part (less than a mtre long). My issue comes how do I know which port wing realization is in the context of the model aircraft breakdown and which in the actual aircraft. My suggested solution to this is to have a relationship between BreakdownElementRealization and BreakdownOf to indicate that this realization is in the context of this application of the breakdown. This could either be as an optional attribute in BreakdownRealization or a relationship object between them. | 5 | Open | None | philsp | nobody | nobody | |
11 | 3531063![]() |
PLCS PSM Model | Should IdentificationContext on Identifier be mandatory | Should IdentificationContext on Identifier be mandatory? In other words should EVERY id have a context? If this is enforced, then the id of an organization would have to have a context. To avoid infinite references the context of the id of an organization could be the organization. | 5 | Open | None | robbod | nobody | nobody | |
12 | 3531263![]() |
PLCS PSM Model | AssemblyComponentRelationship locationIndicator | AssemblyComponentRelationship locationIndicator should be an Identifier - not a Multilingual string. The AP239 module definition is: location_indicator: the text that identifies this usage of the component in the assembly in a diagram, list, chart, or on a physical piece of equipment. The value of this attribute need not be specified. | 5 | Open | None | robbod | nobody | nobody | |
13 | 3532575![]() |
PLCS PSM Model | InZone composition | The InZone relationship can only exist with a ZoneElementDefinition, hence it should be encapsulated in ZoneElementDefinition | 5 | Open | None | robbod | nobody | nobody | |
14 | 3534082![]() |
PLCS PSM Model | Task and states | AP239ed2 has the following state relationships. TaskElementStateRelationship TaskMethodStateRelationship TaskObjectiveStateRelationship Are they really needed or would it be more consistent to use state assignment ... as we do everywhere else in the model | 5 | Open | None | robbod | nobody | nobody | |
15 | 3548224![]() |
PLCS PSM Model | WorkOrderAssignment missing | There is no possibility to assign a WorkOrder without having to define a DirectedActivity in it. We should have the same capability of assigning a WorkRequest to things for a WorkOrder without defining a DirectedActivity in it. | 5 | Open | None | phoubaux | nobody | nobody | |
16 | 3558969![]() |
PLCS PSM Model | ProductViewDefinition is not in MessageContentSelect | This means that if I want to send you information about a view I have to tell you the version and let you receive all the views and work out the one of interest. | 5 | Open | None | philsp | nobody | nobody | |
17 | 3525113![]() |
PLCS PSM Model | BreakdownContext - is it necessary? | In PLCS PSM BreakdownContext relates the breakdown to the elements in the breakdown. It is not clear which is the top level element in the breakdown. ENTITY BreakdownContext SUPERTYPE OF (ONEOF (FunctionalBreakdownContext, PhysicalBreakdownContext, SystemBreakdownContext, ZoneBreakdownContext)); descriptions : OPTIONAL SET OF Description; classifiedAs: OPTIONAL SET[1:?] OF ClassSelect; sameAs : OPTIONAL SET[1:?] OF ProxySelect; breakdown : BreakdownVersion; breakdownElement : BreakdownElementDefinition; END_ENTITY; 242 BOM does not use BreakdownContext . Instead the BreakdownVersion has two attributes that perform the role of the BreakdownContext . BreakdownVersion .topElement relates the BreakdownVersion to the top breakdown element. Optional BreakdownVersion.additonalElements relates to other breakdown elements in the breakdown. E.g. ENTITY Breakdown_version; additional_elements : OPTIONAL SET[1:?] OF Breakdown_element; additional_ids : OPTIONAL SET[1:?] OF Id_with_context; breakdown_of : OPTIONAL root_element_select; description : OPTIONAL STRING; id : Id_with_context; top_element : Breakdown_element; INVERSE breakdown : SET[1:1] OF Breakdown FOR versions; END_ENTITY; Do we "need" to have BreakdownContext ? Do we ever characterize it? | 5 | Open | None | R2.0 | robbod | nobody | nobody |
18 | 3529692![]() |
PLCS PSM Model | BreakdownElement Version / View | Do we really need exploit blocks for BreakdownElement Version and View? 242 treat the BreakdownElement as a single block with a versionid and no views What business reason do we have for having a view on a BreakdownElement version? | 5 | Open | None | R2.0 | robbod | nobody | nobody |
19 | 3536612![]() |
PLCS PSM Model | GeometricCoordinateSpace | Missing attributes Id and Kind have been dropped. Suggest id : IdentifierSelect; classifiedAs : SET [1;?] OF ClassifierSelect; | 5 | Open | None | R2.0 | philsp | nobody | nobody |
20 | 3544527![]() |
PLCS PSM Model | Explicit entities for ApplicationDomain and LifeCycleStage | When using OWL reference data, any PLCS entity to be classified or proxied, must appear as a class within the OWL ontology. hence, we need to have explicit entities for ApplicationDomain and LifeCycleStage hence change to ENTITY ViewDefinitionContext; applicationDomain : ApplicationDomainSelect; description : OPTIONAL DescriptorSelect; lifeCycleStage : LifeCycleStageSelect; UNIQUE UR1: applicationDomain, lifeCycleStage; END_ENTITY; ENTITY ApplicationDomain; definition : ProxyItemSelect; sameAs : SET[0:?] OF ProxyItemSelect; UNIQUE UR1: definition; END_ENTITY; ENTITY LifeCycleStage; definition : ProxyItemSelect; sameAs : SET[0:?] OF ProxyItemSelect; UNIQUE UR1: definition; END_ENTITY; | 5 | Open | Accepted | R2.0 | robbod | robbod | nobody |
21 | 3562456![]() |
PLCS PSM Model | AnalysisModelObject should be classifiable | AnalysisModelObject should be classifiable | 5 | Open | Remind | robbod | robbod | nobody | |
22 | 3562459![]() |
PLCS PSM Model | RequirementSatisfiedBy should be classifiable | RequirementSatisfiedBy shoudl be classifiable | 5 | Open | Remind | robbod | robbod | nobody | |
23 | 3562460![]() |
PLCS PSM Model | RiskPerceptionContext must be classifiable | The RiskPerceptionContext has no properties. It should be the same as: AnalysisRepresentationContext and have at least a description, sameAs and classifiedAs | 5 | Open | Remind | robbod | robbod | nobody | |
24 | 3534771![]() |
EXPRESS to XMI | Redeclaration of properties | There are a number of EXPRESS entities that have attributes redeclared in their subtypes. E.g. ENTITY Product SUPERTYPE OF (ONEOF (...., Collection,)); ... versions : OPTIONAL SET[1:?] OF ProductVersion; END_ENTITY; ENTITY Collection SUBTYPE OF (Product); SELF\Product.versions : OPTIONAL SET[1:?] OF CollectionVersion; END_ENTITY; When drawing the parametric diagrams, both "versions" properties are available as private parts of Collection Collection has multiple "Versions" attributes, with different types. Should both be visible? Is a bug in the conversion from EXPRESS to XMI? OR Is this just a feature of the Parametric diagrams? If yes ..... then perhaps we should seriously consider doing away with the product/versions supertypes ..... and provided usage guidance Note - I think that this is a feature of the parametric diagram which shows both the supertype and the redeclared subtype property. Looking at the Block in a Block Defn Diagram, it is clear that the Collection just has the inherited/redeclared property | 7 | Open | None | robbod | philsp | nobody | |
25 | 3555625![]() |
PLCS PSM Schematron | Schematron rules obsolet | Some schematron rules are not working anymore since the some attribute names have changed for instance: <sch:pattern id="Identifier_Role2Classification"> <sch:rule context="//Identifier/Role/@uidRef"> <sch:assert test="//Classification/@uid[. = current()]">There is no Classification with a uid corresponding to Role.uidRef!</sch:assert> </sch:rule> </sch:pattern> <sch:pattern id="Identifier_IdentificationContext2IdentificationContextSelect"> <sch:rule context="//Identifier/IdentificationContext/@uidRef"> <sch:assert test="//Identifier/@uid[. = current()] or //Organization/@uid[. = current()]">There is no IdentificationContextSelect member with a uid corresponding to IdentificationContext.uidRef!</sch:assert> </sch:rule> </sch:pattern> should be <sch:pattern id="Identifier_Role2Classification"> <sch:rule context="//Identifier/@idRoleRef"> <sch:assert test="//Classification/@uid[. = current()]">There is no Classification with a uid corresponding to Identifier.idRoleRef!</sch:assert> </sch:rule> </sch:pattern> <sch:pattern id="Identifier_IdentificationContext2IdentificationContextSelect"> <sch:rule context="//Identifier/@idContextRef"> <sch:assert test="//Identifier/@uid[. = current()] or //Organization/@uid[. = current()]">There is no IdentificationContextSelect member with a uid corresponding to Identification.idContextRef!</sch:assert> </sch:rule> </sch:pattern> | 5 | Open | None | phoubaux | mikeward | nobody | |
1 | 3517179![]() |
PLCS PSM XSD | Cardinality of <SameAs> and <ClassifiedAs> | Everywhere the <SameAs> and <ClassifiedAs> elements are defined in the following way: <xsd:element name="SameAs" minOccurs="0" maxOccurs="unbounded"> and <xsd:element name="ClassifiedAs" minOccurs="0" maxOccurs="unbounded"> Therefore a valid data would be (for instance); <DateTimeAssignment> <ClassifiedAs> <ExternalOwlClass uidRef="cl1"/> </ClassifiedAs> <ClassifiedAs> <ExternalOwlClass uidRef="cl2"/> <ExternalOwlClass uidRef="cl3"/> </ClassifiedAs> while the EXPRESS defines: sameAs : OPTIONAL SET[1:?] OF ProxySelect; classifiedAs: OPTIONAL SET[1:?] OF ClassSelect; Both definition are not matching : the xsd basically defines an array of array while the EXPRESS define a simple array. The cardinality on both definition in the xsd should be changed to: <xsd:element name="SameAs" minOccurs="0" maxOccurs="1"> and <xsd:element name="ClassifiedAs" minOccurs="0" maxOccurs="1"> | 5 | Closed | Fixed | phoubaux | mikeward | mikeward | |
2 | 3555616![]() |
PLCS PSM XSD | Abstract ComplexType(s) | There is a set of Complext types in the XSD that should be abstract to match the EXPRESS/SysML: Those are: ManagedResource AnalysisModelObject ValueWithUnit ItemShapeObject TaskElement Probability LocationRepresentation AssemblyViewRelationship RequiredResource ResourceEvent DetailedGeometricModelElement RiskViewDefinition GeometricModelRelationshipWithTransformation ProbabilityGenerator ProductAsIndividualVersion ProbabilityDistribution GeometricPlacementOperation File PropertyValue StructuredTaskElement | 5 | Closed | Fixed | phoubaux | mikeward | robbod | |
3 | 3555619![]() |
PLCS PSM XSD | No namespace defined? | The XSD should define a target namespace : proposal: http://docs.oasis-open.org/ns/plcs/plcsPsm | 6 | Closed | Fixed | phoubaux | mikeward | mikeward | |
4 | 3555620![]() |
PLCS PSM XSD | DateTimeStringProxy not used | The complex type DateTimeStringProxy is defined in the XSD but never used. It is also not existing in the EXPRESS/SysML. | 5 | Closed | Fixed | phoubaux | mikeward | robbod | |
5 | 3555622![]() |
PLCS PSM XSD | Attributes representing references | Some attributes representing a reference to an instance are of type : xsd:token instead of xsd:IDREF This breaks the basic XML validation of a data document. This is the case for the following XML attributes: Identifier.idRoleRef Identifier.idContextRef Classification.classRef Proxy.sameAsRef | 5 | Closed | Fixed | phoubaux | mikeward | mikeward | |
6 | 3556947![]() |
PLCS PSM XSD | root element should be renamed | The root element is currently named "PlcsData". This should be changed to "PlcsDataContainer". | 5 | Closed | Fixed | mikeward | mikeward | mikeward | |
7 | 3556960![]() |
PLCS PSM XSD | root element should be specialization of abstract supertype | The root "PlcsDataContainer" element should be specialization of an abstract "DataContainer" supertype to allow for other specializations - eg "Ap242DataContainer" | 5 | Closed | Fixed | mikeward | mikeward | mikeward | |
8 | 3557265![]() |
PLCS PSM XSD | there should be common & domain specific namespaces | The abstract DataContainer root element should have its own name space (designated for the moment as http://www.tc184-sc4.org/10303/-3000/common - this may change). Specializations of that element (such as PlcsDataContainer or Ap242DataContainer) should then each have their own namespaces (the PLCS-PSM ns is designated for the moment as http://docs.oasis-open.org/ns/plcs/plcsPsm - this may change). | 5 | Closed | Fixed | mikeward | mikeward | mikeward | |
9 | 3557342![]() |
PLCS PSM XSD | xsl / xmi / abstract / true case problem | The current version of the XMI has inconsistent use of case for the keyword "true": isAbstract="TRUE" isReadOnly='true'. This has changed over time (with different versions of the generating software) and can also change when the XMI is opened in an application and is inadvertently saved. Because of these problems (and the case sensitivity of XSL) the current XSD is not declaring abstract="true" for objects that are abstract in the SysML and EXPRESS version of the psm. The XMI is being fixed, but, to be on the safe side) the XSL code should be revised so that it traps both "TRUE" and "true". | 5 | Closed | Fixed | mikeward | mikeward | mikeward | |
10 | 3557388![]() |
PLCS PSM XSD | ref attribute datatypes incorrect | As a means of ensuring AP242 compatibility and reasonable file sizes, some constructs have been condensed and xml attributes of the referencing element (rather than the attribute of a sub element) have been used to hold the referencing string - eg Identifier.idRoleRef. The data type of the referencing attributes in such cases are currently set to xsd:token; they should be set to xsd:IDREF. | 5 | Closed | Fixed | mikeward | mikeward | mikeward | |
11 | 3509259![]() |
PLCS PSM XSD | uid/uidRef - why not id/idRef? | Following PLCS review 8/3/2012 uid/uidRef - why not id/idRef? The reason we used uid/uidref was because the Id was unique in the context of the file. I think that we should stick with uid/uidref | 5 | Closed | None | robbod | nobody | robbod | |
12 | 3512258![]() |
PLCS PSM XSD | An aggregation of referenced blocks must be nested. | An aggregation of referenced blocks must be nested. The current XSD supports: <ActivityActual uid="idEvent"> <ClassifiedAs uidRef="cls1"/> <ClassifiedAs uidRef="cls2"/> </ActivityActua> It should be <ActivityActual uid="idEvent"> <ClassifiedAs> <ExternalOwlClass uidRef="cls1"/> <ExternalOwlClass uidRef="cls2"/> </ClassifiedAs> </ActivityActual> This has been agreed as part of the AP242 harmonization process. | 5 | Closed | None | robbod | mikeward | mikeward | |
13 | 3512717![]() |
PLCS PSM XSD | Use Global complex type for Identifications/descriptions | All Identifications/Descriptions elements are currently defined as inner complex type in main complex type. Use global complex types instead. It would save xsd file size and numbers of code generated classes without changing the data file structure. | 5 | Closed | None | phoubaux | mikeward | mikeward | |
14 | 3518364![]() |
PLCS PSM XSD | Abstract ComplexType(s) | Some complex type should be defined as "Abstract" in the XSD to match the definition of the PSM. And therefore there shouldn't be any element defined for those. - ProbabilityDistribution - PropertyValue - Probability - LocationRepresentation - File - RequiredResource - DetailedGeometricModelElement - ManagedResource - TaskElement - GeometricModelRelationshipWithTransformation - AnalysisModelObject - GeometricPlacementOperation - StructuredTaskElement - ProductAsIndividualVersion - ResourceEvent - ProbabilityGenerator - ValueWithUnit | 5 | Closed | None | phoubaux | mikeward | mikeward | |
15 | 3519774![]() |
PLCS PSM XSD | Wrong <PlcsData> contents | Currently the PlcsData element can contain ProductAsPlanned and ProductAsRealized elements whereas all other subtypes of ProductVersion are always nested in their master Product. This is wrong. | 5 | Closed | None | phoubaux | nobody | robbod | |
16 | 3524664![]() |
PLCS PSM XSD | DateTime | DateOrEventSelect is used as a datatype in Project.*Date, DatedEffectivity.StartBound, DatedEffectivity.EndBound and TimeIntervalWithBounds. The problem is that in these attributes one may uidreference an Activity, but a simple date cannot be given, because content should be empty: <Project uid="id400"> <PlannedStartDate>2012-02-01T00:00:00</PlannedStartDate> </Project> Gives an error in Oxygen: Element 'PlannedStartDate' must have no character or element information item [children], because the type's content type is empty. In many other places DateTimeString is used as the datatype for Date-attributes and it works, but there seems to be a problem with this DateOrEventSelect | 5 | Closed | None | mikeward | mikeward | mikeward | |
17 | 3524666![]() |
PLCS PSM XSD | BreakdownContext | If I have instantiated Breakdown with Version, and BreakdownElement+Version+Definition. I am not able to reference those in a BreakdownContext in order to say to which Breakdown a BreakdownElement belongs to. Instead, in BreakdownContext I am "forced" to create new instances of Breakdown and BreakdownElement: <Breakdown uid="id1000"> <Versions> <ProductVersion uid="id1100" xsi:type="BreakdownVersion"> </ProductVersion> </Versions> </Breakdown> <BreakdownElement uid="id1200"> <Versions> <ProductVersion uid="id12100" xsi:type="BreakdownElementVersion"> <ViewDefinitions> <ProductViewDefinition uid="id12200" xsi:type="BreakdownElementDefinition"> <Contexts></Contexts> </ProductViewDefinition> </ViewDefinitions> </ProductVersion> </Versions> </BreakdownElement> <BreakdownContext uid="id1300"> <Breakdown> <BreakdownVersion></BreakdownVersion> </Breakdown> <BreakdownElement> <BreakdownElementDefinition> <Contexts></Contexts> </BreakdownElementDefinition> </BreakdownElement> </BreakdownContext> | 5 | Closed | None | mikeward | mikeward | mikeward | |
18 | 3525625![]() |
PLCS PSM XSD | root element needs changes | The name root element in data files (currently "PlcsData") should be held as a variable in the XSL so that it can easily be changed, and the complex type corresponding to this element should be declare separately as a named complex type (rather than an anonymous nested complex type) as this provided greater flexibility. Implemented in plcslib/xsl/generate_xsd/plcs_psm_xmi2xsd.xsl revision 1.14 and plcslib/data/PLCS/psm_model/plcs_psm.xsd revision: 1.18 | 5 | Closed | None | mikeward | mikeward | mikeward | |
19 | 3525801![]() |
PLCS PSM XSD | there is now no need to declare elements (globally) | In the past (this was "inherited" from part 28) all the elements corresponding to sysML blocks were declared globally (not under the root element) because the XSD used the element ref mechanism. These declarations are now redundant (and also contain the danger that an implementer might instantiate one of these elements at the root of a data file. These declarations should now be removed from the XSD and should not be generated by the XSL. | 5 | Closed | None | mikeward | nobody | mikeward | |
20 | 3526533![]() |
PLCS PSM XSD | tns namespace prefix should be removed | This was inherited from the part 28 default schema used earlier. This is now redundant and can be removed form the schema. | 5 | Closed | None | mikeward | mikeward | mikeward | |
21 | 3528813![]() |
PLCS PSM XSD | defined types | Rather than defining simple types (corresponding to EXPRESS defined types) in the XSD for DateTimeString, CharacterString, Identifier, LengthMeasure, and Uri; we should "collapse" these to their equivalent XSD base types (respectively: xsd:dateTime, xsd:string, xsd:token, xsd:double, and xsd:anyURI. | 5 | Closed | None | mikeward | mikeward | mikeward | |
22 | 3529708![]() |
PLCS PSM XSD | xsd needs revising in line with revised sysML | Major changes have been made to Classification, SameAs, Identification, and Description mechanisms, Cahnges to the XSL, XSD and config file are required in order to deal with these changes. | 5 | Closed | None | mikeward | mikeward | mikeward | |
23 | 3530180![]() |
PLCS PSM XSD | two relationship objects should not be embedded | It is no always possible/appropriate to embed ProductDefinitionElementRelationship and BreakdownElementRealization in their "parent" objects so these RelationshipObjects should be "stand alone" | 5 | Closed | None | mikeward | mikeward | mikeward | |
24 | 3531501![]() |
PLCS PSM XSD | schematron should be used to enforce referential integrity | XML Schema (XSD) cannot be used to enforce referential integrity between arbitrarily nested elements where the name of the referencing relationship element and the target element clash (even though there is a clear type distinction.] Schematron gets round this problem and should be used in place of the key / keyref mechanism. XSD should still be used to enforce type integrity and file structure. | 5 | Closed | None | mikeward | mikeward | mikeward | |
25 | 3535983![]() |
PLCS PSM XSD | updates to address latest changes to psm | <!-- pattern for a block that references a block that is a descendent of Product, ProductVersion, or ProductViewDefinition --> added in plcslib/xsl/generate_sch/plcs_psm_xmi2sch.xsl revision: 1.3 adn and plcslib/data/PLCS/psm_model/plcs_psm.sch revision: 1.4 | 5 | Closed | None | mikeward | mikeward | mikeward | |
26 | 3540416![]() |
PLCS PSM XSD | Enable different config files | The XSLT for generating the XSD is hardcoded to use the plcs config file. Change to allow different config files rto be used. | 5 | Closed | None | robbod | robbod | robbod | |
27 | 3541556![]() |
PLCS PSM XSD | Attribute documentation repeated in XSD | Correct the XSD generation It reads all the attribute definitions for a given name | 5 | Closed | None | robbod | robbod | robbod | |
28 | 3534250![]() |
PLCS PSM XSD | XSD AssignedPropertyValues | AssignedPropertyValues has no children There does not appear to be a way of assigning the value of a property According to the model .. it should be encapsulated Expected: <ProductVersion uid="idMyBikeVersion" xsi:type="ProductAsRealized"> <ViewDefinitions> <ProductViewDefinition uid="paiv1" xsi:type="ProductAsIndividualView"> <InitialContext uidRef="idViewDefnContext"/> <PropertyValueAssignment> <AssignedPropertyValues> <NumericalValue uid="idLifeProperty"> <Definition uidRef="idCycling_hours"/> <Unit uidRef="idHours"/> <ValueComponent>10</ValueComponent> </NumericalValue> </AssignedPropertyValues> </PropertyValueAssignment> </ProductViewDefinition> </ViewDefinitions> | 9 | Closed | None | R1.0 | robbod | mikeward | mikeward |
29 | 3535396![]() |
PLCS PSM Model | ExternalClass - sourceId | Right now we have: ENTITY ExternalClass; description : OPTIONAL DescriptorSelect; externalId : IdentifierSelect; sourceId : OPTIONAL IdentifierSelect; UNIQUE ur1: externalId, sourceId; END_ENTITY; We have a requirement to specify that the source of the class is Document. Obviously we could assign a document in the role of the source but we think that it would be better if we change the model and made the source explicit. We would like to propose: TYPE ExternalClassSource = SELECT (Document, IdentifierSelect); END_TYPE; ENTITY ExternalClass; description : OPTIONAL DescriptorSelect; externalId : SingleIdentifierSelect; source : OPTIONAL ExternalClassSource; UNIQUE ur1: externalId, source; END_ENTITY; | 5 | Closed | Fixed | robbod | robbod | robbod | |
30 | 3535426![]() |
PLCS PSM Model | SingleIdentifierSelect | At present all identifier usages make use of IdentifierSelect. In 99% of these usages I believe this to be correct. However in some cases – such as ExternalItem I think the ability to have IdentifierSet is wrong (especially when this is the only selectable item for the PLCS PSM). We would like to propose a slightly different structure as follows: TYPE SingleIdentifierSelect = SELECT (Identifier, IdentifierString); WHERE encapsulated: SIZEOF(USEDIN(SELF,''))=1; END_TYPE; TYPE IdentifierSelect = SELECT (SingleIdentifierSelect, IdentifierSet); WHERE encapsulated: SIZEOF(USEDIN(SELF,''))=1; END_TYPE; We would then change ExternalItem to use ENTITY ExternalItem; description : OPTIONAL DescriptorSelect; externalId : IdentifierSelect; sourceId : OPTIONAL SingleIdentifierSelect; UNIQUE ur1: externalId, sourceId; END_ENTITY; | 5 | Closed | Fixed | robbod | robbod | robbod | |
31 | 3540771![]() |
PLCS PSM Model | AlternatePartRelationship redeclaration of attributes | The PLCS PSM model currently has: ENTITY AlternatePartRelationship SUBTYPE OF (AlternateProductRelationship); SELF\AlternateProductRelationship.alternateProduct : Part; SELF\AlternateProductRelationship.baseProduct : Part; END_ENTITY; ENTITY AlternateProductRelationship SUBTYPE OF (ProductRelationship); alternateProduct : Product; baseProduct : Product; criteria : OPTIONAL MultiLingualStringSelect; UNIQUE UR1: alternateProduct, baseProduct; END_ENTITY; ENTITY ProductRelationship SUPERTYPE OF (ONEOF (AlternateProductRelationship, CollectionRelationship, RiskRelationship)) SUBTYPE OF (RelationshipObject); id : OPTIONAL IdentifierSelect; relating : Product; related : Product; END_ENTITY; This means that the AlternatePartRelationship effectively has the attributes alternateProduct : Product; baseProduct : Product; relating : Product; related : Product; which is a duplication This should be changed so that the AlternatePartRelationship has relating : Product; related : Product; This will be consistent with other relationships | 5 | Closed | Fixed | R1.0 | robbod | robbod | robbod |
32 | 3531360![]() |
PLCS PSM Model | Rename Assembly structures | Assembly structures is one area where PLCS is harmonizing with AP242. As part of this the proposal is to introduce occurrences for use in assemblies as opposed to just a straight relationship between partviewdefinitions. What we would like to do is design the harmonized model so that we can continue to use the current approach in PLCS and then add occurrence later in a backward compatible way. The intention is to propose the change to PLCS in the second release of the PSM. However, as part of the harmonization, the proposal is rename the assembly relationships so that they are compatible with 242. Rename as follows: AssemblyComponentRelationship = > AssemblyViewRelationship NextAssemblyUsage => NextViewUsage PromissoryUsage => PromissoryViewRelationship | 5 | Closed | Fixed | R2.0 | robbod | robbod | robbod |
33 | 3538988![]() |
PLCS PSM Model | Use of proxy for definition objects incorrect | At present the following objects are defined by a proxy object: ApplicationDomain ExternalPropertyDefinition ExternalUnit LifeCycleStage StateDefinition By "defined by" I mean have a mandatory sameAs attribute defined to be: sameAs : SET[1:?] OF ProxySelect; UNIQUE UR1: sameAs; My first problem with this is that the ProxySelect = Proxy -> ProxyItemSelect This results in us being able to have two different ApplicationDomain's that use two different Proxy's that both point to the same ExternalOwlObject for Product_life_cycle_support. None of the uniqueness constraints are broken since the uniqueness constraint is on the proxy not theProxyItemSelect. My second issue is that in the template OASISViewDefinitionContext there is no mechanism for assigning multiple proxies (hopefully all defining the same thing!) to either ApplicationDomain or LifeCycleStage. If the intent is to only point to a singular definition then the model should be constrained to ensure this. Based on these issues I think we should change these definitional objects to be more like: sameAs: ProxyItemSelect; this may be more in line with the harmonized model as well. | 8 | Closed | Fixed | R2.0 | philsp | robbod | robbod |
34 | 3546351![]() |
PLCS PSM Model | CollectionAssignment.assignedTo | It should be possible to assign a Collection to Person. PersonInOrganization, PersonType, OrganizationType There are probably other things that it should be assigned to as well | 5 | Closed | Fixed | R2.0 | robbod | robbod | robbod |
35 | 3547573![]() |
PLCS PSM Model | WorkRequest: Mandatory versionId ? | WorkRequest shouldn't have a mandatory versionId. Actually wondering if it should have versionIds at all. | 5 | Closed | Fixed | R2.0 | phoubaux | robbod | robbod |
36 | 3547589![]() |
PLCS PSM Model | Extend Select: JustificationAssignmentSelect | Add WorkRequest to JustificationAssignmentSelect | 5 | Closed | Fixed | R2.0 | phoubaux | robbod | robbod |
37 | 3554802![]() |
PLCS PSM Model | TaskElement encapsulation incorrect | TaskElement is encapsulated where ever used, this includes TaskElementRelationship which is incorrect. Suggest we apply the same approach as used for PropertyValue encapsulation and explicitly exclude the relationships from the encapsulation rules. | 8 | Closed | Fixed | R2.0 | philsp | robbod | robbod |
38 | 3555611![]() |
PLCS PSM Model | Element "Classification' should be Root Element | The complex type "Identifier" define the "role" attribute as a reference. According to the schematron rule this attribute should point to a Classification. But Classification is not a top root element in the XSD (not in PlcsData). The following serialization is impossible : <PlcsData> <Organization uid="i3"> <Id> <Identifier id="ANORG" idRoleRef="i2"/> </Id> </Organization> <Classification uid="i2" classRef="i1"/> <ExternalOwlClass uid="i1"> <Class>http://docs.oasis-open.org/ns/plcs/oasis-rdl-en#Identification_code</Class> </ExternalOwlClass> </PlcsData> | 8 | Closed | Fixed | R2.0 | phoubaux | robbod | robbod |
39 | 3490825![]() |
PLCS PSM Model | Assign security to Envelope | It should be possible to assign a security classification to an envelope. | 5 | Closed | None | robbod | robbod | robbod | |
40 | 3490916![]() |
PLCS PSM Model | Ensure slects in PSM align with Select population inAP239 | Add the following to: ActivityAssignmentSelect PropertyDefinitionAssignment, Add the following to: ApprovalAssignmentSelect PropertyDefinitionAssignment Add the following to: ConditionAssignmentSelect PropertyDefinitionAssignment Add the following to: ConditionEvaluationAssignmentSelect PropertyDefinitionAssignment Add the following to: ContractAssignmentSelect ClassSelect ExchangeContextClassLibrary Add the following to: EvidenceSelect PropertyDefinitionAssignment Add the following to: MessageContentSelect SecurityClassification Add the following to: RiskPerceptionSourceAssignmentSelect PropertyDefinitionAssignment Add the following to: SchemeEntryAssignmentSelect PropertyDefinitionAssignment Add the following to: SchemeSubjectAssignmentSelect PropertyDefinitionAssignment Add the following to: SchemeVersionAssignmentSelect PropertyDefinitionAssignment Add the following to: StateDefinitionAssignmentSelect RiskAttitudeValue Add the following to: TaskAssignmentSelect PropertyDefinitionAssignment | 5 | Closed | None | robbod | nobody | robbod | |
41 | 3509257![]() |
PLCS PSM Model | Use of BasicIdentification | Following PLCS review 8/3/2012 The model currently uses BasicIdentification as a contextless identification intended only to be used for identifying Organizations . The recommendation from PLCS was that this supertype is removed, and we only use the sub type Identification making IdentificationContext optional. The resulting EXPRESS would be: ENTITY Identification SUBTYPE OF (BasicIdentification); classifiedAs : OPTIONAL SET[1:?] OF ClassSelect; identifier : Identifier; descriptions : OPTIONAL SET[1:?] OF Description; identificationContext : OPTIONAL IdentificationContextSelect; END_ENTITY; | 5 | Closed | None | robbod | nobody | robbod | |
42 | 3509258![]() |
PLCS PSM Model | Description | Following PLCS review 8/3/2012 The description attribute on Description results in XML that <Descriptions><Description><Description> which is a bit confusing. The recommendation is that the "description " attribute is renamed "text" The Description -> localized string – should be 1 or many It was also felt that having a DescriptionSelect allowing a description to be either a LocalizedString or Description was unnecessary and confusing. It would be better to remove the select. The XML would always be <Descriptions> <Description> <Text> <LocalizedString uid="id02">My Product</LocalizedString> </Text> </Description> </Descriptions> And never: <Descriptions> <LocalizedString uid="id02">My Product</LocalizedString> </Description> The resulting EXPRESS would be: ENTITY Description; identifications : OPTIONAL SET[1:?] OF Identification; classifiedAs : OPTIONAL SET[1:?] OF ClassSelect; text : SET[1:?] OF LocalizedString; descriptionContext : OPTIONAL SET[1:?] OF IdentificationContextSelect; END_ENTITY; | 5 | Closed | None | robbod | robbod | robbod | |
43 | 3509260![]() |
PLCS PSM Model | SingleIdentification - why have this exception? | Following PLCS review 8/3/2012 Why not enforce what is in the model? The reason for SingleIdentification was to reduce file size. I have some example files .. We can test to see whether file size is still an issue. So instead of: <Activity uid="id82"> <SingleIdentification uid="id02" id="p007" idContextRef="id03" idRoleRef="id06"/> </Activity> We would have <Activity uid="id82"> <Identifications> <Identification uid="id02"> <ClassifiedAs uidRef="id06"/> <Identifier>p007</Identifier> <IdentificationContext uidRef="id03"/> </Identification> <Identifications> </Activity> | 5 | Closed | None | robbod | nobody | robbod | |
44 | 3512423![]() |
PLCS PSM Model | PropertyValueAssignment.assignedPropertyValue | PropertyValueAssignment.assignedPropertyValue shoudl eb PropertyValueAssignment.assignedPropertyValues as assignedPropertyValue : SET[1:?] OF PropertyValue; | 5 | Closed | None | robbod | robbod | robbod | |
45 | 3512428![]() |
PLCS PSM Model | File.descriptions | Add descriptions to a File ENTITY File ABSTRACT SUPERTYPE OF (ONEOF (DigitalFile, Hardcopy)); identifications : OPTIONAL SET[1:?] OF Identification; versionIds : OPTIONAL SET[0:?] OF Identification; containedDataType : OPTIONAL ClassSelect; classifiedAs : OPTIONAL SET[1:?] OF ClassSelect; locations : OPTIONAL SET[1:?] OF ExternalItem; descriptions : OPTIONAL SET [1:?] OF Description; END_ENTITY; | 5 | Closed | None | robbod | nobody | robbod | |
46 | 3518736![]() |
PLCS PSM Model | PropertyValue.qualification should be renamed PropertyValue. | As PropertyValue qualification : OPTIONAL SET [1:?] OF MeasureQualification; is a SET PropertyValue.qualification should be renamed PropertyValue.qualifications (plural form – just renaming) | 5 | Closed | None | robbod | nobody | robbod | |
47 | 3518743![]() |
PLCS PSM Model | WorkOutputAssignment.assignedto | The attribute WorkOutputAssignment.assignedto should be WorkOutputAssignment.assignedTo | 5 | Closed | None | robbod | robbod | robbod | |
48 | 3518745![]() |
PLCS PSM Model | QualificationAssignment assignedTo | The QualificationAssignment block inherits from AssignmentObject Hence there should be an assignedTo attribute ENTITY QualificationAssignment SUBTYPE OF (AssignmentObject); assignedQualificationType : QualificationType; receivedBy : QualificationAssignmentSelect; END_ENTITY; shoudl be ENTITY QualificationAssignment SUBTYPE OF (AssignmentObject); assignedQualificationType : QualificationType; assignedTo : QualificationAssignmentSelect; END_ENTITY; | 5 | Closed | None | robbod | nobody | robbod | |
49 | 3518747![]() |
PLCS PSM Model | JustificationSupportAssignment assignments wrong | The PLCS PSM has the follwoing ENTITY JustificationSupportAssignment SUBTYPE OF (AssignmentObject); assignedJustification : Justification; supportItem : JustificationSupportAssignmentSelect; END_ENTITY; AP239 has: ENTITY JustificationSupportAssignment SUBTYPE OF (AssignmentObject); assignedJustification : Justification; supportItem : JustificationSupportAssignmentSelect; END_ENTITY; The definition for a JustificationSupportAssignment is: "A Justification_support_assignment is the association between a Justification and the item providing evidential support for the Justification . " Hence the PSM does not reflect the semantics of the assignment correctly. It is assigning a support item to the justification. Hence the PSM should be ENTITY JustificationSupportAssignment SUBTYPE OF (AssignmentObject); assignedTo : Justification; assignedSupportItem : JustificationSupportAssignmentSelect; END_ENTITY; | 5 | Closed | None | robbod | nobody | robbod | |
50 | 3518750![]() |
PLCS PSM Model | ActivityMethodAssignment assignments wrong | The naming of the assignment attributes for ActivityMethodAssignment is inconsistent with the naming convention for AssignmentObjects In the PSM we have ENTITY ActivityMethodAssignment SUBTYPE OF (AssignmentObject); assignedMethod : ActivityMethod; associatedRequest : WorkRequest; END_ENTITY; The associatedRequest attribte does not follow the naming convention Should be ENTITY ActivityMethodAssignment SUBTYPE OF (AssignmentObject); assignedMethod : ActivityMethod; assignedTo: WorkRequest; END_ENTITY; | 5 | Closed | None | robbod | robbod | robbod | |
51 | 3518772![]() |
PLCS PSM Model | Two types of ActivityMethodAssignment | AP239 and hence the PSM has two entities for assigning an activity method. PSM: ActivityMethodAssignment <==>AP239: Activity_method_assignment and PSM: AppliedActivityMethodAssignment <==> AP239: Applied_activity_method_assignment PSM ------------------------ ENTITY ActivityAssignment SUBTYPE OF (AssignmentObject); assignedActivity : Activity; assignedTo : SET[1:?] OF ActivityAssignmentSelect; END_ENTITY; ENTITY AppliedActivityMethodAssignment SUPERTYPE OF (ONEOF (RiskEvent, SchemeEntryAssignment, SchemeSubjectAssignment, SchemeVersionAssignment, TaskElementAssignment, TaskMethodAssignment, TaskMethodVersionAssignment)) SUBTYPE OF (AssignmentObject); assignedActivityMethod : ActivityMethod; assignedTo : SET[1:?] OF AppliedActivityMethodAssignmentSelect; END_ENTITY; ENTITY AppliedActivityMethodAssignment SUPERTYPE OF (ONEOF (RiskEvent, SchemeEntryAssignment, SchemeSubjectAssignment, SchemeVersionAssignment, TaskElementAssignment, TaskMethodAssignment, TaskMethodVersionAssignment)) SUBTYPE OF (AssignmentObject); assignedActivityMethod : ActivityMethod; assignedTo : SET[1:?] OF AppliedActivityMethodAssignmentSelect; END_ENTITY; AP239 ---------- ENTITY Activity_method_assignment; relation_type : STRING; assigned_method : Activity_method; associated_request : Work_request; END_ENTITY; ENTITY Applied_activity_method_assignment; assigned_activity_method : Activity_method; items : SET[1:?] OF activity_method_item; role : STRING; END_ENTITY; We shoudl only have one entity | 5 | Closed | None | robbod | nobody | robbod | |
52 | 3522496![]() |
PLCS PSM Model | Duration - no value | The Duration value with with has no value | 5 | Closed | None | robbod | nobody | robbod | |
53 | 3522499![]() |
PLCS PSM Model | Use of SETs in EXPRESS | The PSM uses: SET[0:?] E.g. ENTITY Part SUBTYPE OF (Product); SELF\Product.versions : SET[0:?] OF PartVersion; END_ENTITY; It would be better to use: OPTIONAL SET[1:?] If you use SET [0:?] the xml will require the element for the attribute with no content - an empty set. Also the PSM uses:OPTIONAL SET Change to OPTIONAL SET[1:?] | 5 | Closed | None | robbod | nobody | robbod | |
54 | 3524261![]() |
PLCS PSM Model | Multiple V Single Ids & Descriptions | The current PSM specifies that anything identified is a set of identifications and that identification has a context. Ap242 has a requirement that It should be possible to identify an object in the following ways -by a simple identifier string in this case the ownership information about the identifier should be provided by a “default context” - by an identifier string together with the information about the “owner” of that identifier - by a number of identifiers, each one identifying the object form an different point of view (e.g. company or department) in this case, it should be possible to relate the identifiers to each other The same requirement is for descriptions | 5 | Closed | None | robbod | robbod | robbod | |
55 | 3524273![]() |
PLCS PSM Model | SinglePropertyIsDefinition | Is there only ONE definition for a requirements? Is the SinglePropertyIsDefinition.representations [1..*] : SinglePropertyIsDefinitionSelect Correct? Should it not be SinglePropertyIsDefinition.representations [1] : SinglePropertyIsDefinitionSelect | 5 | Closed | None | robbod | philsp | robbod | |
56 | 3524716![]() |
PLCS PSM Model | ExternalViewDefinitionContext | The PSM has been designed to be harmonized with Ap242. Hence the introduction of ExternalViewDefinitionContext. The proposal is to remove ExternalViewDefinitionContext and instead have teh follwoing harmonized model. TYPE ApplicationDomainType = STRING; END_TYPE; TYPE LifeCycleStageType = STRING; END_TYPE; TYPE ApplicationDomainSelect = SELECT(ApplicationDomainType, ApplicationDomain); END_TYPE; TYPE LifeCycleStageSelect = SELECT(LifeCycleStageType, LifeCycleStage); END_TYPE; Note: The when using the model into the PLSMt he LifeCycleStageType and ApplicationDomainType will be removed. So that PLCS PSM forces the use of reference data ENTITY ViewDefinitionContext; applicationDomain : ApplicationDomainSelect; description : OPTIONAL DescriptorSelect; lifeCycleStage : LifeCycleStageSelect; UNIQUE UR1: applicationDomain, lifeCycleStage; END_ENTITY; ENTITY ApplicationDomain; sameAs : SET[1:?] OF ProxySelect; UNIQUE UR1: sameAs; END_ENTITY; ENTITY LifeCycleStage; sameAs : SET[1:?] OF ProxySelect; UNIQUE UR1: sameAs; END_ENTITY; | 5 | Closed | None | robbod | robbod | robbod | |
57 | 3525422![]() |
PLCS PSM Model | ProductViewDefinition.contexts | The PLCS PSM has modified the ProductViewDefinition from the modules so that there is just a set of ViewDefinitionContext 242 require there to be an initial context defined. Hence the proposal is to revert to the module definition of ProductViewDefinition namely ENTITY ProductViewDefinition SUPERTYPE OF (ONEOF (PartViewDefinition, ProductAsIndividualView)); id : OPTIONAL IdentifierSelect; classifiedAs: OPTIONAL SET[1:?] OF ClassSelect; sameAs : OPTIONAL SET[1:?] OF ProxySelect; (* contexts : SET[1:?] OF ViewDefinitionContextSelect; *) initialContext : ViewDefinitionContext (* ViewDefinitionContextSelect *) ; additionalContexts : OPTIONAL SET[1:?] OF ViewDefinitionContext (* ViewDefinitionContextSelect *) ; INVERSE ofVersion : ProductVersion FOR viewDefinitions; END_ENTITY; | 5 | Closed | None | robbod | robbod | robbod | |
58 | 3525529![]() |
PLCS PSM Model | Descriptions should be encapsulated | Add the encapsulation where rule into the EXPRESS model for description to ensure all descriptions are part properties. Descriptions should not have independent existence outside the object they are describing. | 5 | Closed | None | philsp | robbod | robbod | |
59 | 3525530![]() |
PLCS PSM Model | Do we really want to describe an individual identifier? | This seems overkill and highly unlikely to be used. It also creates a circular type dependency between identification and description which causes issues in some implementation forms. | 5 | Closed | None | philsp | robbod | robbod | |
60 | 3528609![]() |
PLCS PSM Model | Characterize DescriptorRelationship / IdentifierRelationship | DescriptorRelationship should be characterized I.e. enable assignment of date time etc | 5 | Closed | None | robbod | nobody | robbod | |
61 | 3529341![]() |
PLCS PSM Model | Strings being used for Classification | There are still several entities that have string attributes that are in effect classifications. These should have been removed from the original PSM. E.g. AddressAssignment.addressType InterfaceConnection.connectionType InterfaceDefinitionConnection.connectionType SequencingRelationship.sequencingType ShapeDependentPropertyRepresentation.characteristicType (Though as this is Geometry - leave it) | 5 | Closed | None | robbod | robbod | robbod | |
62 | 3529379![]() |
PLCS PSM Model | Constant in PSM express | The following constant is in the PSM express It is not necessary as the constant do not transfer to the Sysml or XSD Also - it would be better represented as reference data CONSTANT deprecated_entity_data_types : SET[0:?] OF STRING := ['Alias_identification']; pre_defined_type_qualifiers : SET OF STRING := ['minimum', 'maximum', 'nominal', 'specified', 'typical', 'calculated', 'designed', 'estimated', 'measured', 'required', 'set point', 'basic', 'lower deviation', 'upper deviation']; END_CONSTANT; | 5 | Closed | None | robbod | robbod | robbod | |
63 | 3529393![]() |
PLCS PSM Model | Aggregation objects | There a number of Blocks whose purpose is to present a Set or Aggregation For example DescriptorSet, IdentifierSet, TranslatedStringSet It is proposed to create a common supertype: AggregationObject | 5 | Closed | None | robbod | robbod | robbod | |
64 | 3529394![]() |
PLCS PSM Model | AnalysisRepresentationContext | AnalysisRepresentationContext has no attributes Not sure of its purpose. IN AP239e2 ENTITY Analysis_representation_context SUBTYPE OF (Representation_context); END_ENTITY; ENTITY Representation_context; id : identifier; kind : text; INVERSE representations_in_context : SET[1:?] OF Representation FOR context_of_items; END_ENTITY; It should at least be classified / proxied. | 5 | Closed | None | robbod | philsp | robbod | |
65 | 3529396![]() |
PLCS PSM Model | Multilingual strings | A number of attribute are of type LocalizedString This only allows for the representation of a single string in a given language. It does allow the representation of a set of translated strings. Change attributes of type: LocalizedString to attributes of type: MultiLingualStringSelect | 5 | Closed | None | robbod | robbod | robbod | |
66 | 3529764![]() |
PLCS PSM Model | Identifier.identificationContext optional | The Identifier.identificationContext should be optional. That way you can have an Organization with an Id with no context. | 5 | Closed | None | robbod | robbod | robbod | |
67 | 3530463![]() |
PLCS PSM Model | Duration - is it necessary | Do we need to have the explcit value Duration? This is just another property with a unit of time - so why not use the standard property mechanism for representing this. | 5 | Closed | None | robbod | nobody | robbod | |
68 | 3531072![]() |
PLCS PSM Model | SetMembership / Subset | There is no mechansims to define relationships between classes and their members. Add: ENTITY SetMembership; member : ProxyItemSelect; ofSet : ClassSelect; END_ENTITY; ENTITY Subset; subset : ClassSelect; superset : ClassSelect; END_ENTITY; | 5 | Closed | None | robbod | nobody | robbod | |
69 | 3531105![]() |
PLCS PSM Model | ProductViewDefinition.description | ProductViewDefinition should have a description attribute | 5 | Closed | None | robbod | nobody | robbod | |
70 | 3531254![]() |
PLCS PSM Model | Relate WorkRequests | It should be possible to relate two work_requests Raised against 239 as SEDS: http://www.wikistep.org/bugzilla/show_bug.cgi?id=4413 Add: ENTITY WorkRequestRelationship SUBTYPE OF (RelationshipObject); relating : WorkRequest; related : WorkRequest; END_ENTITY; | 5 | Closed | None | robbod | nobody | robbod | |
71 | 3534552![]() |
PLCS PSM Model | DateTimeAssignment - multiple ClassifiedAs attributes | The DateTimeAssignment Block in the PSM appears to have multiple "classifiedAs" attributes with different multiplicities. | 5 | Closed | None | steve_yates | robbod | robbod | |
72 | 3545279![]() |
PLCS PSM Model | Sysml diagrams: incorrect cardinality | A bug in reeper caused incorrrect display of cardinality at the end of a relationship. in the SysML diagram | 5 | Closed | None | robbod | robbod | robbod | |
73 | 3509396![]() |
PLCS PSM Model | Add Activity to WorkRequestAssignmentSelect | Why Activity is not in the WorkRequestAssignmentSelect ? A Request could affect an activity for instance. | 5 | Closed | None | R1.0 | phoubaux | robbod | robbod |
74 | 3524258![]() |
PLCS PSM Model | Classification Assignment characterization | There is a requirement to be able to specify the date at which a classification took place E.g. when did the part go from being a "development part" to a "Mature part" - this should really be a state. So better example E.g. hazardous classification. When did it become hazardous? Who did it The EXPRESS does not allow this as "ClassifiedAs" is an attribute. However, it would map relatively easily to the XML. E.g <Part uid="idBikePart"> <ClassifiedAs> <ExternalOwlClass uidRef="ECL"/> <DateTimeAssignment> <ClassifiedAs> <ExternalOwlClass uidRef="clsDate_actual_extraction"/> </ClassifiedAs> <AssignedDate>2012-02-01T12:00:00Z</AssignedDate> </DateTimeAssignment> </ClassifiedAs> </Part> Proposal is to add an explicit "ClassifiedAs" relationship in addition to the ClassifiedAs attribute. | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
75 | 3529767![]() |
PLCS PSM Model | Multiplicity on "whole" ends incorrect | The multiplicity adornments on the "whole" end of a relationship such as Organization.id is 0..* This is incorrect | 5 | Closed | None | R1.0 | robbod | philsp | robbod |
76 | 3531094![]() |
PLCS PSM Model | NumericalValue instead of REALS | A numerical value is being used in many places where it would be better to use a REAL If a numerical value is used, then a property definition and unit is required which may be inappropriate For example: ENTITY NumericalContext; classifiedAs : OPTIONAL SET[1:?] OF ClassificationSelect; accuracy : NumericalValue; END_ENTITY ENTITY ValueRange SUBTYPE OF (ValueWithUnit); lowerLimit : NumericalValue; upperLimit : NumericalValue; END_ENTITY; ENTITY ValueWithTolerances SUBTYPE OF (ValueWithUnit); tolerancedValue : NumericalValue; lowerLimit : REAL; upperLimit : REAL; END_ENTITY; | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
77 | 3531097![]() |
PLCS PSM Model | NumericalContext description | Add a description to NumericalContext | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
78 | 3531251![]() |
PLCS PSM Model | Requirement_source should contain Person/Organization ... | It should be possible to specify that the source of a requirement is a person / organization Add the following to the select: requirement_source_item Organization Person_in_organization Activity Contract Project Observation | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
79 | 3531258![]() |
PLCS PSM Model | DatedEffectivity - Optional start date | The start date of a dated effectivity is not always known The start_bound should be OPTIONAL and there should be a rule stating that either a start_bound or an end_bound should be provided. | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
80 | 3531267![]() |
PLCS PSM Model | product / version/ view definition inverses | Change the product / version/ view definition inverses to be compatible with 242 Change ProductVersion From: inverse "ofProduct" <-> attribute "versions" To: inverse "versionOf" <-> attribute "versions" ProductViewDefinition From inverse "definedVersion" <-> attribute "viewdefinitions" To: inverse "viewdefinitionOf" <-> attribute "viewdefinitions" This will not affect the XML ENTITY ProductVersion SUPERTYPE OF (ONEOF ( PartVersion, ProductAsIndividualVersion)); id : OPTIONAL IdentifierSelect; description : OPTIONAL DescriptorSelect; classifiedAs: OPTIONAL ClassificationSelect; sameAs : OPTIONAL ProxySelect; viewDefinitions : OPTIONAL SET[1:?] OF ProductViewDefinition; INVERSE versionOf : Product FOR versions; END_ENTITY; ENTITY ProductViewDefinition SUPERTYPE OF (ONEOF (PartViewDefinition, ProductAsIndividualView)); id : OPTIONAL IdentifierSelect; classifiedAs: OPTIONAL ClassificationSelect; sameAs : OPTIONAL ProxySelect; initialContext : ViewDefinitionContext; additionalContexts : OPTIONAL SET[1:?] OF ViewDefinitionContext; INVERSE viewDefinitionOf : ProductVersion FOR viewDefinitions; END_ENTITY; | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
81 | 3531288![]() |
PLCS PSM Model | ExchangeContextClassLibrary libraryIdentification | When referring to an explicit identification, Identification is abrereviated toId e.g. versionIds The ExchangeContextClassLibrary.has a property libraryIdentification Propose to change to libraryId ENTITY ExchangeContextClassLibrary; libraryIdentification : Uri; UNIQUE UR1: libraryIdentification; END_ENTITY; | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
82 | 3531811![]() |
PLCS PSM Model | RequirementSatisfiedBySelect = RequirementAssignmentSelect | Why use select equivalence? TYPE RequirementSatisfiedBySelect = SELECT (RequirementAssignmentSelect); END_TYPE; ENTITY RequirementSatisfiedBy; satisfiedBy : RequirementSatisfiedBySelect; satisfiedRequirement : RequirementViewDefinition; relatedAssignment : OPTIONAL RequirementAssignment; END_ENTITY; It would be more straight forward for code generation to have one select that is used by the entity.attribute. Delete RequirementSatisfiedBySelect and change to ENTITY RequirementSatisfiedBy; satisfiedBy : RequirementAssignmentSelect; satisfiedRequirement : RequirementViewDefinition; relatedAssignment : OPTIONAL RequirementAssignment; END_ENTITY; | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
83 | 3531883![]() |
PLCS PSM Model | Inconsistent redefinition of properties | Redefining element (b) is not consistent with redefined element (a): a - b ContextualItemShape-describedElement is - ItemShape-describedElement, -reason : DescribedElementSelect is not a subtype of ShapeableItemSelect - FunctionalBreakdown-versions is - Breakdown-versions FunctionalElement-versions is - BreakdownElement-versions FunctionalElementVersion-viewDefinitions is - BreakdownElementVersion-viewDefinitions PhysicalBreakdown-versions is - Breakdown-versions PhysicalElement-versions is - BreakdownElement-versions PhysicalElementVersion-viewDefinitions is - BreakdownElementVersion-viewDefinitions RiskVersion-viewDefinitionsis - ProductVersion-viewDefinitions SchemeEntryAssignment-assignedTo is - ActivityMethodAssignment-assignedTo SchemeSubjectAssignment-assignedTo is - ActivityMethodAssignment-assignedTo SchemeVersionAssignment-assignedTo is - ActivityMethodAssignment-assignedTo SystemBreakdown-versions is - Breakdown-versions SystemElement-versions is - BreakdownElement-versions SystemElementVersion-viewDefinitions is - BreakdownElementVersion-viewDefinitions TaskElementAssignment-assignedTo is - ActivityMethodAssignment-assignedTo TaskMethodAssignment-assignedTo is - ActivityMethodAssignment-assignedTo TaskMethodVersionAssignment-assignedTo is - ActivityMethodAssignment-assignedTo ZoneBreakdown-versions is - Breakdown-versions ZoneElement-versions is - BreakdownElement-versions ZoneElementVersion-viewDefinitions is - BreakdownElementVersion-viewDefinitions , reason: ZoneElementVersion-viewDefinitions is not composite while BreakdownElementVersion-viewDefinitions is. | 8 | Closed | None | R1.0 | fredrik_larsen | robbod | robbod |
84 | 3532064![]() |
PLCS PSM Model | Unique rule for Identifier | Unique rule for ENTITY Identifier should be: UR1: idString, role, identificationContext; (instead of idString, classifiedAs, identificationContext | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
85 | 3532428![]() |
PLCS PSM Model | TaskMethod composition | The model for TaskMethod does not use composition. TaskMethodVersion.ofTaskMethod points to TaskMethod TaskMethodVersion.content points to TaskElement It would be better to have the TaskMethod composed of the TaskMethodVersion which in turn is composed of the TaskElement In other words have a structure similar to Product/ProductVersion | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
86 | 3532456![]() |
PLCS PSM Model | DetailedGeometricModelElement encapsulation | DetailedGeometricModelElement and its subtypes should be encapsulated wherever they are used E.g. (AxisPlacement, CartesianPoint, CartesianTransformation2d, CartesianTransformation3d, Direction, GeometricPlacementOperation | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
87 | 3532457![]() |
PLCS PSM Model | GeometricCoordinateSpace encapsulation | GeometricCoordinateSpace should be encapsulated wherever it is used | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
88 | 3532462![]() |
PLCS PSM Model | Risk properties incorrect | The current model is basically the RiskDefinition module re-worked as the PSM without the separation we made on definitions/values being applied I suggest we make the following changes: RiskAttitudeValue is effectively a subtype of PropertyValueAssignment, it is the assignment of a criticalityFactor to a RiskPerception RiskLevelAssignment is already a subtype of PropertyDefinitionAssignment, it is the assignment of a type of property “RiskLevel” to a RiskPerception RiskEventProbabilityAssignment is already a subtype of PropertyDefinitionAssignment and is incorrectly related to the ActivityMethod, it should be related to the RiskEvent since the same ActivityMethod could have different probabilities in different RiskPerceptions Bottom line: Suggest we re-model this area as follows: Add an attribute to RiskPerceprion riskLevel : OPTIONAL PropertyValue; Add an attribute to RiskEvent perceivedProbability : OPTIONAL Probability; Delete the following entities: RiskAttitudeValue RiskLevel RiskLevelAssignment RiskEventProbabilityAssignment RiskEventProbability RiskEventProbabilityValue | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
89 | 3532464![]() |
PLCS PSM Model | Scheme composition | The Scheme elements as shown below are not related via composition relationships Scheme should be composed of SchemeVersion which should be composed of SchemeEntry ENTITY Scheme SUBTYPE OF (ActivityMethod); END_ENTITY; ENTITY SchemeVersion SUBTYPE OF (ActivityMethod); ofScheme : Scheme; END_ENTITY; ENTITY SchemeEntry SUBTYPE OF (ActivityMethod); scheme : SchemeVersion; END_ENTITY; | 5 | Closed | None | R1.0 | robbod | nobody | robbod |
90 | 3532472![]() |
PLCS PSM Model | MeasureQualification composition | MeasureQualification is only used by PropertyValue.qualifications The PropertyValue.qualifications-> MeasureQualification should be a composition | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
91 | 3532485![]() |
PLCS PSM Model | PropertyValue composition | The PropertyValue shoudl always be encapsulated when used, expect when part of an assignment or relationship | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
92 | 3532562![]() |
PLCS PSM Model | RequirementViewDefinition definitionalRepresentations | Each requirement should have a property that defines the requirement. E.g. mass > 10 Kg This is distinct from meta data properties such as stake holder ranking This is currently represented by ENTITY SinglePropertyIsDefinition; definedElement : ProductViewDefinition; representations : SET[1:?] OF SinglePropertyIsDefinitionSelect; UNIQUE UR1: definedElement; END_ENTITY; However, SinglePropertyIsDefinition should be encompassed by the RequirementViewDefinition and furthermore, the meaning is not obvious from the model. It is proposed therefore to delete SinglePropertyIsDefinition and replace with and explicit attribute on RequirementViewDefinition, RequirementViewDefinition.definitionalRepresentations ENTITY RequirementViewDefinition SUBTYPE OF (ProductViewDefinition); definitionalRepresentations : SET[1:?] OF PropertyValue; INVERSE SELF\ProductViewDefinition.viewDefinitionOf : RequirementVersion FOR viewDefinitions; END_ENTITY; | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
93 | 3532564![]() |
PLCS PSM Model | AnalysisDisciplineDefinition definitionalRepresentations | An AnalysisDisciplineDefinition can have a single representation of the model that it is the analysis model. This is currently represented by ENTITY SinglePropertyIsDefinition; definedElement : ProductViewDefinition; representations : SET[1:?] OF SinglePropertyIsDefinitionSelect; UNIQUE UR1: definedElement; END_ENTITY; However, SinglePropertyIsDefinition should be encompassed by the AnalysisDisciplineDefinition and furthermore, the meaning is not obvious from the model. It is proposed therefore to delete SinglePropertyIsDefinition and replace with and explicit attribute on AnalysisDisciplineDefinition , AnalysisDisciplineDefinition .definitionalRepresentations | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
94 | 3532574![]() |
PLCS PSM Model | BreakdownOf composition | The BreakdownOf relationship can only exist with a BreakdownVersion, hence it should be encapsulated in BreakdownVersion | 5 | Closed | None | R1.0 | robbod | robbod | robbod |
95 | 3534624![]() |
PLCS PSM Model | Collection | Collection has multiple "Versions" attributes, with different types. | 5 | Closed | None | R1.0 | steve_yates | robbod | robbod |
96 | 3534625![]() |
PLCS PSM Model | CollectionVersion | ColectionVersion has multiple "VersionOf" attributes with different Types | 5 | Closed | None | R1.0 | steve_yates | robbod | robbod |
97 | 3534626![]() |
PLCS PSM Model | CollectionViewDefinition | CollectionViewDefinition has multiple "ViewDefinitionOF" attributes with different types | 5 | Closed | None | R1.0 | steve_yates | robbod | robbod |
98 | 3529419![]() |
PLCS PSM Model | BreakdownOf more than product | PLCS has an explicit "BreakdownOf" relationship. This is a BreakdownOf of ProductViewDefinition There is a requirement to have a breakdown Blocks other than just ProductViewDefinition E.g.ProductConcept and ProductConfiguration | 5 | Closed | None | R2.0 | robbod | nobody | robbod |
99 | 3534804![]() |
PLCS PSM Schematron | patterns for (implied) references to subtypes missing | Where attribute a of block A references block B and block B is a supertype of blocks C and D, the XSL code should generate three sch patterns: one for A_a2B and two more patterns for A_a2C and A_a2D. At present, only the first type of pattern is being created. | 5 | Closed | None | mikeward | mikeward | mikeward | |
1 | 3525536![]() |
PLCS PSM Model | Do we really want to describe an individual identifier? | This seems overkill and highly unlikely to be used. It also creates a circular type dependency between identification and description which causes issues in some implementation forms. | 5 | Deleted | None | philsp | nobody | philsp | |
2 | 3528524![]() |
PLCS PSM Model | DescriptorRelationship should be characterized | DescriptorRelationship should be characterized I.e. enable assignment of date time etc | 5 | Deleted | None | robbod | nobody | robbod | |
3 | 3532449![]() |
PLCS PSM Model | Scheme composition | The Scheme elements as shown below are not related via composition relationships Scheme should be composed of SchemeVersion which should be composed of SchemeEntry ENTITY Scheme SUBTYPE OF (ActivityMethod); END_ENTITY; ENTITY SchemeVersion SUBTYPE OF (ActivityMethod); ofScheme : Scheme; END_ENTITY; ENTITY SchemeEntry SUBTYPE OF (ActivityMethod); scheme : SchemeVersion; END_ENTITY; | 5 | Deleted | None | R1.0 | robbod | nobody | robbod |