Incorrect scalar style chosen for FLOAT node if value string matches INT pattern

[Tim Quinn]

In Serializer#serializeNode, if the value happens to match the Resolver.INT pattern but the node’s tag is actually FLOAT, then the ImplicitTuple is prepared with false and false and this is used in constructing the ScalarEvent. Eventually this leads the Emitter#chooseScalarStyle method to decide to quote the output, which is not really appropriate for the numeric value.

I think that the change as a result of this earlier issue https://code.google.com/archive/p/snakeyaml/issues/130 actually introduced this behavior which I understand fixed a separate problem.

I am not familiar enough with the code base to suggest a solution. Would it make sense for the resolver to take account of the tag associated with the node and not just try to match the value string to a list of patterns?

[Andrey Somov]

I am not familiar enough with the code base to suggest a solution. Would it make sense for the resolver to take account of the tag associated with the node and not just try to match the value string to a list of patterns?

There is no tag associated with the node.

[Tim Quinn]

In Serializer#serializeNode the Node node parameter has the getTag() method, doesn’t it? That’s what I meant by associated with it.

In debugging the problem I ran into, I was puzzled why a ScalarNode with tag FLOAT was being formatted by the emitter with quotes, until I saw what was happening in serializedNode when it called the resolver which bases its decision only on the value string.

[Andrey Somov]

In Serializer#serializeNode the Node node parameter has the getTag() method, doesn’t it? That’s what I meant by associated with it.

well, it is set by the resolver (via a match to a list of values)

[Andrey Somov]

Tim, you are misusing the issue tracker for general questions. Please use the mailing list.

[Tim Quinn]

This is a bug and, I think, deserves to be in the issue tracker. Please see this reproducer:

https://github.com/tjquinno/snakeyaml-test (BigDecimalTest)

SnakeYAML formats a BigDecimal field with value 10.0 as '10' (with single quotes) but, in contrast, outputs one with value 10.2 as 10.199xxx. My concern is with the quoting, not with the approximation in the value of 10.2.

[Andrey Somov]

Dear Tim, the project you provided does not even compile.

If you expect others to help you, can you please make sure we do not waste time ?

[Tim Quinn]

There was a one-character typo in the pom file – an extra closing } in the version variable substitution for a dependency. I am not sure how it got there, and I apologize. You didn’t past the error, so I assume that is the problem you saw. I have fixed it, and the project builds now and gives the output displayed in the README.md file.

[Andrey Somov]

Let us distinguish your personal expectations from the specification. What is exactly the place in the spec which is not respected?

(as far as I can see the spec is fully supported)

Have your studied the spec ? Have you checked the tags https://yaml.org/type/index.html ?

[Tim Quinn]

My apologies. This looks like a problem in my application code (more involved than the reproducer) that was over-aggressively suppressing tag output. You’re right, there is nothing wrong that I see in what SnakeYAML is emitting in the reproducer.

[Tim Quinn]

This was pilot error, not a problem in SnakeYAML.