Previous directives don't apply to next documents in a YAML 1.1 stream

[bar1y]

According to the requirement of Global Tag Prefix in spec 1.2:

Shorthands using the associated handle are expanded to globally unique URI tags, and their
semantics is consistent across applications. In particular, every documents in every stream
must assign the same semantics to the same global tag.
once the handle of a global tag prefix is defined, it should be available across the source to the following documents.

And unfortunately, the example provided by the spec does not cover the requirement.
Example 6.22. Global Tag Prefix

%TAG !e! tag:example.com,2000:app/
---
- !e!foo "bar"

Use it as a test case is not a good idea.

Try follows instead:

%TAG !e! tag:example.com,2000:app/
---
- !e!foo "bar"
---
- !e!bar "baz"

[eemeli]

I think you may be mixing up two different things here.

First, yes, global tags are meant to be globally unique URIs, so that e.g. tag:example.com,2000:app/bar always means the same thing.

Second, the %TAG directive can define a document-specific shorthand to use as a tag prefix. However, this shorthand only applies to the specific document, even if the current stream includes multiple documents.

So in order to make your stream example work, it'd need to be formatted a bit like this:

%TAG !e! tag:example.com,2000:app/
---
- !e!foo "bar"
...
%TAG !e! tag:example.com,2000:app/
---
- !e!bar "baz"

Also, this sounds a bit like you're raising an issue with the YAML spec rather than yaml, the JS library?

[bar1y]

Issue for the JS library.

I don't think the spec requires people to repeat the the same global tag prefix directive before every document across the source. It's tedious and should be avoided in a fine design.

Every Unity scene file, which is a YAML 1.1 file, defines a global tag prefix once at the beginning:

%TAG !u! tag:unity3d.com,2011:

And use its handle !u! in every document across the same file.

e.g.
https://raw.githubusercontent.com/mistertaftcreates/Unity-Zelda-Like/master/Part%2026/Assets/Scenes/SampleScene.unity

[eemeli]

Ah, drat. There's a difference between the 1.1 and 1.2 specs that I'd missed.

YAML 1.1 says this:

To ease the task of concatenating character streams, following documents may begin with a byte order mark and comments, though the same character encoding must be used through the stream. Each following document must be explicit (begin with a document start marker). If the document specifies no directives, it is parsed using the same settings as the previous document. If the document does specify any directives, all directives of previous documents, if any, are ignored.

YAML 1.2 on the other hand does not include that part, and instead says:

A YAML character stream may contain several documents. Each document is completely independent from the rest.

Furthermore, version 1.2 of the spec does not include a l-next-document construct, to which the 1.1 instruction about following preceding documents' directives applies.

As a point of interest, YAML 1.0 was similarly clear on the matter, but OTOH the %TAG directive was only introduced in 1.1:

Directives apply to a single document.

But yeah, it does look like this should be fixed for YAML 1.1 document streams. Probably with a version-specific option, much like << merge nodes.

[eemeli]

I've released 1.5.1, which fixes next-document handling for YAML 1.1 streams. I didn't add an option flag for it, as both the 1.0 and 1.2 specs specify rather opposite behaviour.

However, that's not enough to make the Unity sample file compile right, as it includes a few documents like this (from line 222):

--- !u!4 &242477465 stripped
Transform:
  m_CorrespondingSourceObject: {fileID: 4289843246717992, guid: 1a0a6b589437e4d40ae72d9407472372,
    type: 2}
  m_PrefabInternal: {fileID: 1019440873}

Note the stripped bit at the end of the first line. In proper YAML, that gets considered as the start of a plain string, which continues on the next line as stripped Transform (the newline gets folded into a space), which is then used as an implicit key of a mapping, even though the key is probably intended to be just Transform. And that's then invalid YAML, as implicit keys are required to be single-line.

[bar1y]

Thanks, @eemeli

It's likely Unity added some non-standard features in their YAML format.
e.g. The GUID values and the stripped bit.

[eemeli]

Actually the GUIDs are fine, those are just YAML anchors. It's the stripped suffixes to some of them that are the broken bit. I'm closing this issue for now, as I think I've done as much as I reasonably can here.