[Yaml-core] meeting minutes 20 jun 2002

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

---
summary: >
  Today we had a short meeting today where Oren, Brian and
  I agreed to a bunch of changes.  I am hoping that this is the
  last "big" change to the spec as it reflects lessons learned 
  over the last few months.  This set of changes will 'clean-up' 
  the recent set of in-line features that hit the spec last week.  
  Further, it addresses a slew of type family related items which
  have grown in importance over the last few months.  Thanks!
changes:
  dates:
    summary: >
      Drop time/date transfers, rename timestamp to time,
      make date portion mandatory with an optional time/zone
      portion defaulting to noon, gmt (+00); note that the
      T is optional (a slight extension of ISO 8601)
    rationale: >
      Time by itself needs to be attached to a date in order
      to do any substantial built-in time operations.  Also,
      most languages have a time structure that includes date
      (or has mandatory date).  Also YAML needn't have 3 data 
      types for this particular requirement.
  numbers:
    summary: >
      Add note about floating point numbers not always being
      preserved (1.1 for example has non-exact representation),
      specifying that it should behave according to IEEE rules
      (as implemented by C's date) or better.
    rationale: >
      This is a clear limitation of using the "double" construct
      to round-trip YAML information may not be perfect, this notice
      is needed to awaken people about it.  Especially those using
      the floating point notion to store currency.  We talked about
      introducing a currency/fixed point type; this was tabled at
      the current time since it may be too domain specific.
  string:
    summary: >
      The regex for string implicit type will be anything starting
      with alpha numeric (including underscore) that does not match
      the numeric implicits (time, float, integer).  We do not intend
      to add any more primary implicits, instead all new implicits
      will be added within parenthesis; so in the future if a URL 
      type were to be added, it would be parenthesized such as
      (mailto:cc...@cl...)
    rationale: >
      IP addresses, telephone numbers, and other numeric tuples currently
      require quoting.  Further, it was hard to tell if something was a 
      string or not a string.  This rule makes it a bit more flexible but
      also clear; if it isn't a number or date, it's a string.  Note
      that this is permanent change and will not allow stuff like
      un-parenthesized IP addresses or telephone numbers to be made
      implicit in the future.
  boolean:
    summary: >
      We've added two implicit regex for boolean, true will be
      represented by + and false by -.  Thus, "flag: +" can be 
      used to succicently handle boolean values.  Also, bool will
      have parenthesized forms as currently specified, (true), (false),
      (yes),(no),etc.
    rationale: >
      It's nice to have a shorter way to express boolean values,
      the + and - seemed to work just perfectly and were not attached
      to any other meaning.  
  null:
    summary: >
      The implicit ~ is maintained, although (null) is also added as
      a parenthesized form.
    rationale: >
      We've grown accustom to ~, it is clean.  We wanted (null) as
      an equivalent to (true) and (false).  
  flow:
    summary: >  # not discussed with Oren/Brian
      the simple and quoted scalars will be collectively referred
      to as flow scalars since they are not block or folded.
    rationale: >
      we need some word to refer to them, in-line doesn't work
      beacuse it tends to imply inside a in-line collection.  ;(
  simple:
    summary: > 
      unquoted flow scalars used as keys and used inside a nested
      collection will not be allowed to span multiple lines.
    rationale: >
      Doing otherwise isn't very clear or pleasing to the eye.  Furthermore,
      it complicates comment handling.   For example...

        --- [ "Quoted string  # this is not a comment, it is content
               that continues on the second line" # this is a comment,
               Unquoted strings # comment? or no?
               that continue are a bit more problematic # another comment ]

      The ambiguity above caused by third line above, "# comment? or no?" 
      caused ambiguity which would be hard to explain.  Thus the limitation
      of unquoted in-line scalars to a single line.
    note: >
      How to address this comment ambuguity within the top-level flow
      (non nested) was not discussed; Clark thinks off-hand that the
      comment should be allowed to trail the flow scalar, but not
      appear in the middle.
  quoted:
    summary: > 
      quoted strings spanning multiple lines will have all leaing/trailing
      whitespace converged into a single space; blank lines (two new lines
      with only whitespace between) are treated as a single line. 
      In particular, indentation is not preserved.
    rationale: >
      This made the best sense since quoted strings are follow the
      flow pattern.