Thomas Smith

From [3.2.1.3](https://yaml.org/spec/1.2.2/) (emphasis added): > A YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-models) *may* treat equal [scalars](https://yaml.org/spec/1.2.2/#scalars) as if they were identical. In general, a YAML document may contain nodes that are equal to each...

> *equal-but-not-identical nodes* don't have any difference in the token stream. What do you mean by “the token stream”? Is this a NetworkX concept?

> https://github.com/yaml/pyyaml/blob/main/lib/yaml/tokens.py It's hard to talk about nodes in terms of tokens because a node in the representation graph may correspond to zero, one, or many tokens. But a node...

> This made me wonder if the spec is really defining graph structure. Shouldn't vertices and edges be sets? Eh. It's traditional to define formal directed graphs in as something...

Hypergraphs seem like overkill to me. Off the top of my head, a reasonably simple encoding might use labelled directed graphs: - Each YAML node gets a graph vertex. -...

https://spec.yaml.io/pr-242

I generally agree. I think that in this case there is value to having a quick, formal-but-not-complete listing of the information models and processes before the detailed descriptions in the...

The issue is that there are two sections named e.g. “Streams”, and they get the same autogenerated ID, and both TOC links will go to the first one. HTML documents...

> What does "semantically equivalent" mean in this context? I presume that it must refer to the spec's notion of node equality. Under that definition, all three of the the...

> So `[[], []]` and `[&arr [], *arr]` are also equal and canonicalized the same way? That sounds like a footgun in case anyone mutated the data structures deserialized from...