Confusing error message “unknown node type”, caused by the YAML schema

[johannessen]

YAML config on 1.3.1-diagnostics (f1c193596c13e107d43f33e7b11a53694f0ace1c):

- individual_directory:
    - Alfa: 555666777

Expected

The entry is accepted, because it has a legal name and a MMSI with the correct length.

Actual

The entry is rejected, with the error message “unknown node type”.

Discussion

The error message is technically inaccurate, the node type is known to be scalar. But the average user is probably unfamiliar with such specific YAML terminology, which means this error message is potentially confusing.

Apparently the YAML parser applies the YAML Core Schema, which results in 555666777 being treated as a number. However, that value does match the correct format for a MMSI. There is no ambiguity at all. Therefore, it should just work.

Another symptom of the same problem is evident in entry names:

- individual_directory:
    - Null: "555666777"

“Null” is a completely legal (albeit perhaps uncommon) name for a boat. More to the point, in this particular context, it’s absolutely clear that Null is the boat’s name and is meant to be resolved to tag:yaml.org,2002:str rather than tag:yaml.org,2002:null. However, what actually happens is the same error message “unknown node type” being shown.

Apart from Null, there are some other scalars that aren’t resolved as strings in the Core Schema and therefore cause this issue when used as a name, e. g. True, 42, .Inf.

Proposal

It would appear that the Core Schema is not perfectly suited for our purposes. I think we should consider defining a custom YAML schema.

If that doesn’t pan out, at minimum we should try to restrict the parser to the Failsafe Schema.

[johannessen]

Possibly another symptom of the same problem:

- channels:
    group_1:
      names:
        - 6:

With channel 6 included in the list, but no string provided as a channel name, it would be logical to expect the channel name to be the empty string "". However, the app actually sets the channel name to the string "null".

[mbof]

Thanks. In the first case, it was intentional to force quotes around the MMSI. This is because the ones that start with a zero will have ambiguous results otherwise (they'll be parsed as number and would have to be padded somehow). I looked at how users were generating these directories using spreadsheet formulas and felt it would be safer if the format didn't change from entry to entry. Maybe the failsafe scheme would allow this to work unambiguously though.

[johannessen]

Right.

By the way, even in the Core Schema, output and input can follow different rules. Just because the output always quotes scalars doesn’t mean the input can’t accept quoted as well as unquoted scalars (at least those that aren’t ambiguous).

[mbof]

I tried the failsafe schema, but it broke some other things. For expediency I put a one-line local fix instead.

[johannessen]

I don’t think a better error message resolves this issue.

[mbof]

Sorry you're right. I just added an error message to explain the expected format wrapping an MMSI in quotes but it's still reasonable to consider that this should work.

[johannessen]

Thanks for reopening. I think fixing the error message was a good first step.

The Failsafe schema basically treats everything as a string. This is related to YAML’s roots in Perl, which can use string scalars transparently in numeric context. In JavaScript, you’ll need to do some manual work, such as parseInt() fields you want to be numeric, and match( /true|on/i ) fields you want to be boolean.

[mbof]

Yep failsafe broke some bool flags. I tried to find a way to tweak the YAML library being used in order to make both things work without having to add more parsing code but no dice, so indeed some custom parsing would need to be added on top of the failsafe schema.