Open trans opened 12 years ago
What is the reason for radically modifying the syntax? Wouldn't it be possible to just allow a "simplified" parser to ignore tags and resolve every node according to its type only?
In a round about way you've hit the nail on the head. The main reason to consider a Simplified YAML specification are the parser implementations. Consider the proliferation JSON implementations compared to YAML, and the fact that almost all reasonably complete YAML implementations are bindings to LibYAML --despite YAML being around for much longer. Clearly there is a complexity to the YAML specification that makes it difficult to implement.
So this issue is an exploration of one possibility for what might be done to improve upon this situation. In particular, tags account for one of the complexities that adds to the burden of implementers, while being one the features of YAML that has a broad set of use cases in which they are never used.
The reason I suggest using comments is b/c a Simplified YAML specification should not have to even think about tags. If you have to add conditions to the spec to ignore them, then you've already taken them, at least in part, into account.
Thinking about simplification, perhaps a simplified variation of YAML could be made that lacks tags altogether, and then modify the current serializable specification to handle tags as annotated comments.
Example of simplified YAML:
Then YAML 2.0 could handle tags like so:
Yet it would remain parseable with the simplified YAML b/c simplified YAML would just ignore the tags as comments.
The only tricky part here is that inline tags would make the whole line look like a comment. So either a bracketed notation would be needed in this case or a tags could be suffixed instead, or both e.g.
Or
Or
Directives too would be annotated comments.