Implicit types are not supported about yamlbeans

From [email protected] on February 16, 2011 22:32:43

I don't believe guessing at the type based on the content is a good idea in general. It is less important for YamlBeans, where typically YAML is deserialized to objects, where the class definition is used for the schema.

Primitive type wrappers are expressed as null by a YAML field with an empty value. There is currently no way to express a null for other references. I will open a new issue as a task to add support for a !null tag.

Slightly more info in this thread:
http://groups.google.com/group/yamlbeans-users/browse_thread/thread/19dba370af58b9fd/2111f1ad42b77382

Status: WontFix

From [email protected] on February 17, 2011 01:53:58

It is not guessing it is defining. When you wish '1' to be a String instead of an integer you say !!str "1".
It is an indication that YamlBeans does not cover complete YAML 1.1 specification.

From [email protected] on February 17, 2011 02:04:25

YamlBeans' goal is to go from Java objects to YAML and vice versa using the minimal YAML markup. Type definitions come from the Java class definition, not from the YAML markup. Even if it did not conflict with YamlBeans' goals, implicit typing is a bad idea. This could be why it appears to be removed from the YAML 1.2 specification.

From [email protected] on February 17, 2011 04:05:32

It stays in YAML 1.2 ! But fortunately, it was dramatically reduced.
Can you please provide a link which shows it was removed ?
This the specification for an integer: http://www.yaml.org/spec/1.2/spec.html#id2803828
Please read: "... matching the regular expression 0 | -? [1-9] [0-9]*"

Does it mean that YamlBeans does not have plans to support complete 1.2 in the future ?

From [email protected] on February 17, 2011 04:26:58

At the top of the 1.2 spec it says, "We have removed unique implicit typing rules and have updated these rules to align them with JSON's productions."

You linked to section "10. Recommended Schemas". Again, YamlBeans uses the Java class definition as the schema. YamlBeans has no need for guessing at types using regex or verbose type tags. Again, YamlBeans is for Java to YAML to Java with minimal YAML markup. It is not for cross-platform data exchange. I do not care if YamlBeans does not implement optional portions of the spec. In fact, the specs' complexity is the reason that YAML will never see widespread adoption. Writing a parser is simply too hard.

You are the SnakeYAML author. You are not a user of YamlBeans. If you were, you'd be pleased that YamlBeans does what it intends to do (do I really need to repeat it again?) with an elegant API, tailored specifically for that purpose. If you need features beyond what YamlBeans was intended for, then I suggest using a different library, where you will pay the cost of a more complex API and uglier YAML markup.

From [email protected] on February 17, 2011 05:46:32

At the top of the 1.2 spec it says, "We have removed UNIQUE implicit typing rules and have updated these rules to align them with JSON's productions.". It used to have 18 (!) values boolean but it is only 2 in 1.2. This is better.
If you somehow indicate that YamlBeans does not implement the complete 1.1 and is not going to support complete 1.2 then it would not confuse users. If you clearly state which parts of the specification are not implemented and why then users would try to avoid using optional features especially when they have to use a few parsers. Why not to mention it in your documentation ?
At the moment I am busy preparing the document with SnakeYAML/YamlBeans comparison. I would like to collect precise information about both. I do not know how to build YamlBean. How do you build it ? I do not know how to create a coverage report. Are you interested in creating together an unbiased comparison table ?

From [email protected] on February 17, 2011 15:12:37

YamlBeans users don't try to use optional features. They have no need to. You are trying use cases that are atypical for YamlBeans users.

YamlBeans is a source directory containing Java files. You can compile it with Maven, Ant, Scar, Netbeans, Eclipse, javac, etc. There is nothing special about compiling it. You can also use the provided JAR.

My issue with your comparison page in the past is that you use it to sell your library while spreading FUD about other libraries. Potential users should choose a library on their actual merits. We have all worked hard on our libraries and it isn't right for them to be misrepresented. This can occur even when the facts are correct. It would be easy to make it appear that one library is better than others by using careful comparison tables and commentary. Having spoken with you publicly and privately over the past almost 3 years, I don't know you are capable of an unbiased comparison. Working together with you has failed in the past and I see no reason why this would be different.

YamlBeans excels at serializing Java objects to YAML and back using minimal YAML markup and an easy to use API. YamlBeans can parse YAML from other sources to Java objects, but because this is not its primary goal, some of the more esoteric features from the YAML specification may not be supported. If would be nice if this is conveyed in your comparison page. It might make sense to have code snippets showing how Java objects are round tripped, along with what the YAML looks like.

It shouldn't be hard to have something good to say about each library.