When did YAML become a derivative work of JSON?

I was reading through the Specification today (http://www.yaml.org/
spec/1.2/spec.html), something I hadn't done in some time, and found
it rather curious that JSON has taken such a prominent role in the
specs. I understand having a section to discuss the relationship
between YAML and JSON, but not some of the references that appear to
actually co-op aspects of the JSON spec for YAML.

Examples:

---
2.4. Tags
  ...
In YAML, untagged nodes are given a type depending on the application.
The examples in this specification generally use the seq, map and str
types from the fail safe schema. A few examples also use the int,
float, and null types from the JSON schema. The repository includes
additional types such as binary, omap, set and others.
---
4.1. Production Parameters
  ...
In flow styles, explicit indicators are used to delineate structure.
These styles can be viewed as the natural extension of JSON to cover
tagged, single-quoted and plain scalars. Since the latter have no
delineating indicators, they are subject to some restrictions to avoid
ambiguities. These restrictions depend on where they appear: as
implicit keys directly inside a block mapping (block-key); as implicit
keys inside a flow mapping (flow-key); as values inside a flow
collection (flow-in); or as values outside one (flow-out).
---
5.1. Character Set
  ...
To ensure JSON compatibility, YAML processors must allow all non-
control characters inside quoted scalars. To ensure readability, non-
printable characters should be escaped on output, even inside such
scalars. Note that JSON quoted scalars cannot span multiple lines or
contain tabs, but YAML quoted scalars can.

[2]	nb-json	::=	 #x9 | [#x20-#x10FFFF]
---

etc. etc.

And part 7.x is just full of references to JSON.

The whole specification starts to come off as if it's a derivative
work of JSON.

I would like to see all these taken out of the specification. They can
be moved instead to whole new chapter detailing the relationship and
how to be compatible. I think the first mention of JSON in the spec
makes it clear:

"It may be useful to define a intermediate format between YAML and
JSON. Such a format would be trivial to parse (but not very human
readable), like JSON. At the same time, it would allow for serializing
arbitrary native data structures, like YAML. Such a format might also
serve as YAML’s "canonical format". Defining such a “YSON” format
(YSON is a Serialized Object Notation) can be done either by enhancing
the JSON specification or by restricting the YAML specification. Such
a definition is beyond the scope of this specification."

Well apparently it's not really beyond this specification since
references to JSON compatibility are now littered throughout the YAML
spec. We should take this advice and create just such a format --make
it a separate chapter or another document. But let's have the YAML
spec stand on it's own. After all it proceeds JSON by many years!





------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2