Skip to content

Track YAML 1.2.2 gap backlog and PowerShell API design alignment #71

Description

Context

The spec folder now captures YAML 1.2.2 conformance gaps and capability backlog items that need implementation issues. These items should be delivered in a way that fits idiomatic PowerShell: rich objects, predictable pipeline behavior, and clear parameter sets that separate projection, parsing, formatting, and compatibility modes.

Official YAML 1.2.2 reference:

Current State

Several YAML behaviors are already implemented or partially implemented. Existing open issues also cover some related areas, especially timestamp parsing, presentation/comment preservation, and representation-preserving entry removal. The newly created issues split the remaining gaps into focused delivery leaves.

Objective

Track the YAML 1.2.2 gap backlog and keep related issues aligned so implementation work can proceed in small, focused slices without duplicating scope.

Backlog Map

Conformance and safety

Schema and tag extensibility

Emission and presentation

YAML 1.1 compatibility and representation-preserving operations

PowerShell projection and command surface

PowerShell Design Principles

  • Prefer explicit parameters over hidden behavior changes.
  • Use parameter sets to make projection modes and incompatible output modes discoverable.
  • Preserve current defaults unless a conformance correction or major-version breaking change is explicitly declared.
  • Keep rich object output useful while rejecting YAML representations that would otherwise lose data silently.
  • Keep ConvertFrom-Yaml/Import-Yaml parameter symmetry and ConvertTo-Yaml/Export-Yaml parameter symmetry.
  • Keep Test-Yaml Boolean and pipeline-friendly while surfacing warnings through normal PowerShell warning streams.
  • Use classified error identifiers for automation.

Acceptance Criteria

  • Each linked issue has a clear YAML 1.2.2 reference or PowerShell command-surface rationale.
  • Existing overlapping issues are linked to the new focused issues rather than duplicated.
  • Implementation PRs can close one delivery leaf at a time.
  • Breaking changes are explicitly marked and scoped.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions