The row ActorPart in table 8.3 should depict SysML::Blocks::PartProperty typed by UML4SysML::Actor, but it shows an Actor.

Resolution: Show properties typed by Actor in ActorPart row of table 8.3

The row ActorPart in table 8.3 shows Actor elements instead of properties typed by an Actor.

SYSML17-286 asks for removing the row ActorPart from the table.

The second constraint of the stereotype AllocateActivityPartition references a section in the UML specification:

"To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic."

Subclause 12.3.10 does not exist. It is probably 15.6.3.1 in UML 2.5.1.

I propose to remove the subclause reference number.

AllocateActivityPartition: Reference to UML specification

The subclause number references an older version of the UML specification. It is hard to manage those links between separate specifications. Therefore, we follow the proposal of the issue author to remove the absolute reference.

The comments in the XMI that specify the documentation of the stereotypes and stereotype attributes do not annotate the elements they document.

I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

I believe that this is a new issue for SysML 1.3.

An “X” on a single end of an association to indicate that an end is not navigable has similarly been dropped

Does this statement mean that SysML has no concept of non-Navigation (only unspecified)... or does it mean that if you
have an association end A has no Navigation shown, end B has Navigation shown... then End A should be interpreted as
being non-Navigatable...

The standard would indicate this as it says "has been similarly dropped" which means it is not shown but it is there all the same...

The version of the specification document that is supposed to have changebars does not appear to have any changebars or redlines. This makes it unnecessarily difficult to find out what has changed since the released 1.5 spec.

National patent offices require patent drawings in a very specific format. The “parts” of an invention must typically be numbered consistently, and always indicated with a solid line from each part number to the part.

I have found many applications can be represented well as SysML Parts Property symbols, and with convenient correct propagation of part numbers across diagrams (Single Source of Truth).

I have been re-appropriating Comment for this using the following diagramming “hack" in the MagicDraw/Cameo tool:

• Use the Documentation field of a Part Property to hold each unique part number.

• Use the Retrieve Documentation feature to display that part number in a Comment symbol (which is stereotyped «Documentation»).

• The HACK: hide the border of the Comment by making it white against white background, and also hide the stereotype.

But then you have to use an external image editing tool to tediously make the dashed lines all solid to meet the patent office's requirements.

Note that UML2.5.1 states:

'The connection to each annotatedElement is shown by a separate dashed line.’

A refinement of this proposal might involve creating a special new dedicated SysML element to achieve this, with a dedicated attribute for carrying the numbering.

It is beyond the scope of this initial proposal to specify how the capability might be achieved.

The proposal is not limited to numbering and indicating SysML Part Properties typed by Blocks, it could be applied to other Element kinds, but Part Properties lend themselves immediately to the purpose.

This proposal does not yet elaborate on how the numbering sequence might be handled (largely a tool feature matter).

The section '7 Model Elements' is a candidate for specification of the new proposed element.

[Diagrams illustrating the required result will be provided via JIRA once the proposal issue ticket is raised]

Reference: IP Australia: Best Practice Guide: Appendix: Examples of Drawings: https://www.ipaustralia.gov.au/sites/g/files/net856/f/best_practice_guide_appendix_iv.pdf

I'm not sure if this is actually an issue (I think it is). There are 2 keywords in Figure E.10: Spring Length Example; <<valueType>> and <<ValueType>>. Wondering if it is the same keyword and the latter should be lowercase v.

Elements starting from Namespace Compartment to InstanceSpecification (9 items Elements total) is listed twice in the 8.2.1 Block Definition Diagram: Table 8.1.

Refine::getRefines(in ref : NamedElement) : AbstractRequirement should return NamedElement according to the definition of the refine stereotype in section 16.1. The body condition of the operation is not consistent with the return type AbstractRequirement.

There is no constraint that restricts that one end of the refine relationship must be an element of type AbstractRequirement.

Trace::getTracedFrom(in ref: NamedElement) : AbstractRequirement should return NamedElement according to the definition of the trace stereotype. The body condition should be updated as well from AbstractRequirement to NamedElement.

The sentence in section 16.1 "A generic trace requirement relationship provides a general-purpose relationship between a requirement and any
other model element." is too restrictive with regard to the definition of the trace stereotype.

As defined in the UTP element Verdict, the SysML VerdictKind should also define an enumeration literal none:

none The test case has not been executed yet.

When a test case is not executed yet or just invoked, its verdict is none. None indicates that no communication between
test components and the SUT has been carried out yet. None is the weakest verdict. It is never set by the tester directly.