[Yaml-core] YAML 1.0 => YAML 1.1 Compatibility

[Clark C. E. <cc...@cl...>]

I just finished a beer with Mark, a friend of mine (a PyYAML and
soon to be Syck user), and we talked about YAML 1.1.  He really
liked the %TAG idea, but was very concerned about breaking his
documents, which I guess are at several client sites, etc. 

I reviewed the compatibility issues with him:

---
-
  issue: we are getting ride of the ^ character in tags
  reason:
    this mechanism is replaced by the %TAG method
  solution:
    Parsers can warn, but continue to provide current
    cut & paste behavior; in other words, this does not
    create an ambiguity.
- 
  issue: the %YAML:1.0 declaration is not per document
  reason:
    headers are now stream level
  solution:
    Newer parsers can simply warn for now, as this case
    is not ambiguous.
-
  issue: "23" and 23 are parsed the same
  note: this has not yet been approved by Brian
  reason:
    plain style flag is no longer reported to appliction
  solution:
    - if the document has either of the above two items,
      it is clearly a 1.0 document, and backward-compatible
      behavior is possible
    - if the document contains %YAML 1.1 directive, then
      it is clearly 1.1 document, and the distinction can
      be safely ignored
    - in YAML 1.1, there really isn't a need to use the
      double-quoted "23", so all other cases should ignore
      the distinction, but issue a warning; and perhaps 
      install a parser option
- 
  issue: ! vs !! types
  reason:
    beacuse it is deemed that private types are more 
    important and should get the simple form?
  solution:
    If it is clearly 1.0 or 1.1 document, there is no problem.
    Otherwise, the user will most likely encounter a 'tag not
    resolved' error if things are confused.

Anyway, a few more notes about our conversation:

- His driving reason for using YAML over 'shelve' or similar Python
  serialization was: (a) promise of being able to read the files
  from Perl, and perhaps eventually Java, (b) and readability a
  'distant' second.

- He uses the 'strings-are-king' version of PyYaml, with frequent
  !!private types and an occasional !yaml type (for integers). He
  expressed frustration with the implicit typing, and thought it
  should be strictly optional (see below).

- He didn't care one way or the other about 23 vs "23", as his
  particular application doesn't mix numbers and strings (aka he 
  has a context-based schema).

- He expressed that he'd rather not see ! and !! swapped.  He
  reiterated that the promise of multi-language data files was the
  primary reason for adopting YAML.   He expressed that he'd like to
  see more YAML types, like !regex, !url and other "botique" data
  types.  He thought a smarter YAML Dumper would use more !yaml
  types instead of making them private.

- He suggested a %REGEX directive that maps regular expressions onto
  tags.  He said he'd consider implicit typing only if it was
  explicitly in the file so there was no chance of a "mixup".
  
- He very much would like better parsers, emitters, and asked
  when we will have a schema language to help with validation.
  He asked about the "Java Version" about 5x stating that he'd
  love to share the same configuration/data files between 
  the perl junkies, the python heads, and the Java people.

After this conversation, I got to thinking a bit about the last
item, swapping "!" and "!!".  My friend went so far to say that it
was a 'fine decision', and was not convinced by our rationale to
change it. As a side note, if we didn't swap their meaning we keep
backwards compatibility with PyYaml, and also, we can explicitly
type something a string by using ! 23  instead of !! 23.  So.  Do we
really want to swap ! and !! -- anyone care to chime in?

Kind Regards,

Clark