Re: example 7.17 in YAML 1.2 spec 2009-07-21

Oren,

> On Thu, 2009-10-01 at 09:02 +0900, Osamu TAKEUCHI wrote:
>> Your definition does not seem to increase readability.
>> Let me show some examples...
> 
> I'm fine with them. IMO interpreting a::::: as either "a::::": or
> "a:::::" is hard to understand. Some people will "obviously" see it as
> one, some will "obviously" see it as the other, both groups with the
> same level of conviction. That's not readable; a readable construct has
> only one "obvious" interpretation. And readability is our #1 goal.
> 
>> The idea is that ':' is treated as part of the plain text
>> unless it is followed by a delimiter in the context, which
>> includes a space and a line break.
> 
> You make a good case and I can see how this would seem consistent on its
> own. But - I feel it is inconsistent with the spirit of other YAML
> indicator rules. In general we tend to interpret indicators as
> indicators by default, unless there's some good reason not to - as
> opposed to the other way around. E.g., we decided to disallow the
> oh-so-attractive 1,000,000.00 format for numbers - we always treat an
> unquoted ',' as a separator. The winning argument there was again
> "unsurprising" readability: what does {1,234} mean?

Do you really think the following?

{abc}      is obviously      { "abc" : null }
{abc:}     is obviously      { "abc" : null }
{abc::}    might be read as  { "abc::" : null }
{abc:: a}  might be read as  { "abc::" <missing> "a" }

I do not see how you got this idea. :(
Could you please explain why the last ":" character in "abc::" can 
be read as a non indicator character?

My reason why it must be read as an indicator character is very 
simple, because it is followed by a delimiter "}" as same as the 
case of "abc:".


> Finally, there's also the question of giving ourself a way to back out
> of bad decisions (which you may feel this one to be :-). I'd much rather
> play it safe and make trailing ':' characters an error for now. If this
> turns out to be a mistake, it is easy to change the rules to allow them,
> while maintaining compatibility with all existing files. If on the other
> hand we start allowing them now, then decide this was a mistake, it
> would be harder to switch back - as this would break once-valid files.

The compatibility across revisions does not support your proposal.

Let's study some examples.

+---+----------+--------------------+-------------------+-------------------+
| # | Input    |   old rule         |  my rule          |  your rule        |
+---+----------+--------------------+-------------------+-------------------+
|(1)| {abc: }  | { "abc"   : null } | { "abc"  : null } | { "abc"  : null } |
|(2)| {abc:}   | { "abc:"  : null } | { "abc"  : null } | { "abc"  : null } |
|(3)| {abc:: } | { "abc:"  : null } | { "abc:" : null } | error!            |
|(4)| {abc::}  | { "abc::" : null } | { "abc:" : null } | error!            |
+---+----------+--------------------+-------------------+-------------------+

Note that these four inputs had been valid YAML 1.2 documents before the patch. 
This behavior was explained, and is still explained as the following.

>>  Normally, YAML insists the “:” mapping value indicator be separated from 
>> the value by white space. A benefit of this restriction is that the “:” 
>> character can be used inside plain scalars, as long as it is not followed by 
>> white space. This allows for unquoted URLs and timestamps. It is also a 
>> potential source for confusion as “a:1” is a plain scalar and not a key: value 
>> pair.

It clearly says that the ":" character can be used inside plain scalars,
as long as it is not followed by a white space (or a line break, in reality).
This statement is almost the same as my proposal. I wonder if you think this
is inconsistent with the spirit of other YAML indicator rules.

So, the following input had been also allowed without any uncertainty.

- abc:: def
- 
  ? abc::
  def
- 
  abc:: def
- [ abc:: def ]

The only one problem was the inconsistency between (1) and (2), and 
(3) and (4). Since ":" in (2) and (4) are not followed by a white space, 
they were included in the plain text in the old rule. Such a case only 
occurs when ":" is followed by an indicator character, namely one of 
"{", "}", "[", "]" and "," in the flow context. Although this behavior 
was not very much incompatible to the description in the spec, the result 
was confusing.

Since Example 7.17 suggested that the spec writer (you?) thought {abc:} 
should have been accepted as { "abc" : null } contrarily to the old BNF 
syntax, I proposed a new rule as:

  The ':' character can be used inside plain scalars, as long as it is not
  followed by a delimiter in the context, which includes a space, a line 
  break and other indicators depending on the context.


So, it was very surprizing for me that you suddenly decided not to 
accept {abc:: } any more. It had nothing to do with the problem I pointed 
out. At least, you can not justify your proposal by the possible future
compatibility because your proposal is, by itself, too much incompatible 
to the old rule, and even to the description in the current spec. 
Your patch already broke once-valid files and probably still-valid files.
My current proposal is merely reviving such files.


If you still think your new rule is superior, let's discuss how we should
explain its behavior, its benefit and its compatibility, instead of 
suddenly introducing it in the spec.

Best,
Osamu TAKEUCHI


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf