[Bug]: PIM DTOs deviate from the normative API PIM model (ptc-25-02-29) #388

What type of issue is this?

• Bug report
• Feature request

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of the SysML2.NET
• I have searched open and closed issues to ensure it has not already been reported

Description

Several SysML2.NET.PIM.DTO types deviate from the normative Systems Modeling API and
Services PIM UML model (OMG document ptc-25-02-29). Two of the four make parts of the API
model unrepresentable, so a PSM mapping cannot round-trip. Each deviation below is confirmed
by both the UML model and the §7.1 prose.

Item 1 is the most severe: QueryService::createQuery and Query.where cannot carry any
real filter.

Members present in the normative model but absent from the PIM DTOs:

• Commit.change : DataVersion [1..*] and Commit.versionedData : DataVersion [0..*]
  (change is mandatory, and is an input of createCommit)
• Project.branches : Branch [1..*], Project.tags, Project.commitReferences
  (§7.1.2: "A Project can have 1 or more branches")
• Query.orderBy : String [0..*]
• DataVersion.project : Project [1..1]

And PrimitiveConstraint.value is [1..*] in the model; the SDK's List<string> Value = []
carries no lower bound.

Steps to Reproduce

1. PIM/DTO/PrimitiveConstraint.cs declares public class PrimitiveConstraint with no base,
   while PIM/DTO/CompositeConstraint.cs is : Constraint. Assigning a PrimitiveConstraint
   to Query.Where does not compile.
2. PIM/DTO/Query.cs — no Project member, no OrderBy member.
3. PIM/DTO/Commit.cs — PreviousCommit is Guid; no Change or VersionedData members.
4. PIM/DTO/Project.cs — no Branches, Tags or CommitReferences members.

System Configuration

• SysML2.NET version: 0.24.1
• Environment (Operating system, version and so on): Windows 11, any
• .NET Framework version: net10.0 / netstandard2.1
• Additional information: found while implementing the REST/HTTP PSM mapping in
  mycelium-fabric, where items 1 and 2 are currently worked around by answering 501 for
  primitive constraints and threading the project id in from the route.