fix(json-cppagent): emit schemaVersion from agent config, not hardcoded#145
Draft
ottobolyos wants to merge 18 commits intoTrakHound:masterfrom
Draft
fix(json-cppagent): emit schemaVersion from agent config, not hardcoded#145ottobolyos wants to merge 18 commits intoTrakHound:masterfrom
ottobolyos wants to merge 18 commits intoTrakHound:masterfrom
Conversation
ottobolyos
force-pushed
the
fix/issue-128
branch
2 times, most recently
from
19671cd to
688178e
Compare
ottobolyos
force-pushed
the
fix/issue-128
branch
2 times, most recently
from
8364565 to
35993f7
Compare
Replace the hardcoded `SchemaVersion = "2.0"` assignment in both ctors of `JsonMTConnectStreams` with a derivation from `IStreamsResponseOutputDocument.Version`. The default ctor leaves SchemaVersion null (consumers must set it via the property initializer or the document-accepting ctor); the document-accepting ctor pulls the value from the response document, formatted two-segment (e.g. `"2.5"`) to match cppagent's wire output. Closes TrakHound#128 once the matching Devices fix lands.
Mirror the Streams envelope fix on the Devices side: replace the hardcoded `SchemaVersion = "2.0"` with a derivation from `IDevicesResponseDocument.Version`. Default ctor leaves SchemaVersion null; document-accepting ctor populates it from the response document. Closes TrakHound#128.
The docs/testing/issue-128/ subtree carried phase-by-phase campaign writeups that referenced internal tooling (CONVENTIONS rule-book, internal section numbers, extra-files.user/ paths, internal tracker terminology). Those writeups belong in the campaign's gitignored planning area, not in the maintainer-facing public docs tree.
Lands the in-flight work for the issue-128 review pass: - `JsonMTConnectStreams.SchemaVersion` carries an XML doc explaining the envelope-vs-Header semantics: the top-level `schemaVersion` identifies the document envelope schema (the wire format the producer chose), distinct from `Header.schemaVersion` which identifies the agent's configured MTConnect Standard release. - `JsonDataItemPropertyCasingTests` pins the cppagent JSON wire-shape casing convention via reflection: complex-object members stay PascalCase (`Source`, `Constraints`, `Filters`, `Definition`, `Relationships`) while scalar attribute members stay camelCase (`category`, `id`, `type`). - `Issue128_HardcodedLiteralGuardTests` consumes a new shared `TestHelpers/RepoRootLocator` which walks up from the test bin directory until it finds the `MTConnect.NET.sln` sentinel. Future source-surface guards reuse the helper rather than re-implementing the walk.
Adds a regression fixture pinning the cppagent JSON wire-format
contract that the envelope `schemaVersion` and the `Header.schemaVersion`
must coexist as INDEPENDENT fields:
- both are wired through their own [JsonPropertyName("schemaVersion")]
attributes;
- both live on distinct declaring types so they can be populated from
independent sources (envelope: producer's wire-format choice; Header:
agent's configured Standard release);
- each `SchemaVersion` property must carry an XML doc comment that
mentions the words "envelope" AND "Header" so the contrast between
the two surfaces stays explicit to future maintainers.
Two test cases currently fail: the `SchemaVersion` properties on
`JsonMTConnectDevices` (envelope) and `JsonDevicesHeader` lack the
explanatory XML doc. Adding the docs lands in the green half of the
TDD pair.
This commit is the red half. The XML wire-shape is unchanged; this
is purely a source-comment guard backed by reflection / source-text
inspection.
Adds XML doc comments to the two `SchemaVersion` properties that the red guard fixture flagged as missing: - `JsonMTConnectDevices.SchemaVersion` (envelope, Devices document): identifies the envelope schema the producer chose to emit. - `JsonDevicesHeader.SchemaVersion` (Header, Devices document): identifies the agent's configured MTConnect Standard release. Both docs explicitly contrast the envelope-vs-Header semantics so a future maintainer cannot accidentally collapse the two fields without the source-text guard tripping. The wire format is UNCHANGED: each property continues to serialize under the camelCase JSON key `schemaVersion` at its respective surface (envelope root vs. Header object). The change is purely documentary.
ottobolyos
force-pushed
the
fix/issue-128
branch
from
35993f7 to
c8a5889
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #128 —
MTConnectStreams.schemaVersionandMTConnectDevices.schemaVersionwere hardcoded to"2.0"in both ctors ofJsonMTConnectStreamsandJsonMTConnectDevices, ignoring the agent's configuredDefaultVersion. The cppagent JSON-MQTT format contract requires the configured MTConnect release to reach the wire.Versionproperty, formatted two-segment ("2.5") to match cppagent's wire output.schemaVersionvs. nestedHeader.SchemaVersion) is unambiguous to consumers."2.0"literal in the two touched files.