Ingy dot Net wrote:
On 17/04/07 17:40 -0400, Clark C. Evans wrote:
  
Kenneth,

short answer:
  You should be able quote those Y/N items to force them 
  to be a string.

long answer:
  You might be able to configure your parser to not "implicitly
  type" Y/N as a boolean value.  

longest answer: >
  You've hit the #1 usability prooblem with YAML, it's called "implicit
  type resolution" and different implementations are doing it
  differently.  
  
  The original goal was to make it easy to type in integers and have
  them show up as integers w/o littering your text with "!!int".
  Unfortuntely, where that line should be drawn is a bit hard.

  In the next pass of YAML, I am going to recommend that all parsers
  _only_ do implicit typing on:
  
    (a) symbolic values, such as <<, which can be used to 
        augment the YAML syntax /w very nice hooks
        
    (b) numbers, "true" "false" and "null", following
        the JSON standard (for compatibility)

  At least, this should, IMHO, be the default.  I think Ingy begs
  to differ and believes the default should be *all strings* with
  no implicit typing.  What ever we come up with, getting there 
  is sure to be unpleasent; but probably far less unpleasant than
  the current state of affairs.
    

I disagree but in specifics, not in spirit. The "Parser" should not do typing
of any form. It reports for each scalar, a char-string value, and whether the
scalar was plain or not.

A yaml "Load" operation consists of at least 3 steps, "parse", "compose",
"construct". According to the spec, introduction of node "tag" (aka "type")
happens in the composer.

Whatever...

Your point is that we got too cute with the default implicit types. String,
Integer and Number are fine as a default.

I would reccomend that all implementations support a everything is string mode. 
  

I would ask, what is simplest and most consistent.  And also, how did the conversation start?

The conversation started because these two elements (is that the right word?) give different results:

item:
  prop_1st: value    # yields the string "value"
  prop_2nd: Y         # yields a numeric 1!  Newbie says huh??

What options are available?

1) Tweak default behavior.  Pro: Might satisfy this case.  Con: Might break older files, or require them to be version-stamped.  Con: Will just be an invitation to more tweaking and nobody will ever be happy.  Con: will create a list of incompatible versions with incomprehensible variations (this is the end-result of taking this road).  Think HTML 3, html 3 for ie, html 4, html 4 for ie, html 4 for mozilla pre 6, mozilla 6, etc etc etc.

2) Support for header directives for the possible options.  Possible directives:

none: follow behavior from before directives became available, so my Y above becomes a 1

"booltrue: Y, 1, Yes, YES", some kind of explicit list of values that will be treated as boolean true.  If my Y is not listed it wont be treated as a boolean.

boolfalse: same as booltrue, list of false values

date: xx-xx-xxxx,  anything that fits the picture is treated as a date.

numdigits: Treat any string composed only of numerals as a number

...others as they come to mind.  Those are off the top of my head, a real effort would have to be made to seek the list of directives that served all purposes without overlap or missing possibilities.

3) Declaring types for named properties. In the above example I would declare in the header that "prop_2nd" is a string.

4) Type-casting at the definition, which I believe is supported now with "tags".

If Ken were calling the shots, option 1 would be thrown out, option 4 is already supported, so supporting options 2 and 3 would produce the general solution, and then it becomes a matter of programmer preference and then you wait for best practices to emerge through community use of the various approaches.



-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-379-7200   Fax: 631-689-0527