yaml / YAML2

An Effort to Revitalize the YAML Project and Community
43 stars 5 forks source link

Simplified YAML and Tag Annotations #2

Open trans opened 12 years ago

trans commented 12 years ago

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:


---
foo: 1
bar: 2

Then YAML 2.0 could handle tags like so:

--- #! tag:foo.org/foobar,2012
foo: 1
bar: 2

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.


---
foo: #(int) 1

Or


---
foo: 1 #!int

Or


---
foo: 1 #(int)

Directives too would be annotated comments.

# %TAG !foo! foo.org,2012
tanriol commented 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?

trans commented 12 years ago

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.