Re: [Yaml-core] A test

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

Here is a more tangable proposal.  

#1  We introduce "type" into the information
    model.  Thus we have a colored (type)
    graph where each node can either have
    labeled arrows (with no label the same)
    or an ordered set of arrows.

#2  We have 4 scalars:

    a) The "implicitly typed" scalar, this lacks 
       an indicator and is limited to a single
       line.  Examples include:

       date: 2001-02-23
       int: 23
       float: 23.0
       currency: USD$23.00

    b) The quoted sclaar:

       single: "Single line quoted."
       multi: 
          "This is a multi\
           line quoted scalar.\n"
       same: "\
           This is a mutlti\
           line quoted scalar.\n"      
 
    c) The simple scalar:

       single: 'Simple scalar'
       multi: '
           This is a simple mult-line
           scalar value.

    d) Block scalar:

       block: |
           This is your
             standard block.

    Notes:

    a) If a typed scalar was encoutered by
       the parser, without an appropriate
       matching type "registered", then a
       warning would be issued, and the
       value would be treated as a 
       quoted/simple/block scalar.

    b) The difference between the above
       scalar forms is not included in
       the information model...

   
    c) If Brian doesn't like the fact that
       the simple scalar has an indicator,
       you can give the typed scalar an
       indicator instead, i.e.,

      
       date:  `2001-03-23
       amount: `USD$30.30
       integer: `23
       float:   `2.34

       Frankly, I like this better, but
       I didn't want to ruffle feathers.

#3)    Any node can be given a type
       using the !bang.  We will make
       the following equivalency...

       detected: `23
       implicit: !org.yaml.integer "23"

       And, of course, if a type isn't
       supported on a given platform/language, 
       a warning is issued, and the type 
       information is dropped.

       Thus, we probably need a unique
       naming system for classes... but
       this isn't so hard.  Two basic
       solutions, reverse DNS and/or
       a IANA registry, plus some sort
       of local escape mechanism for
       "language specific types" that
       have no hope of round-tripping.

#4)    The list and map do not need an
       indicator.  And we don't have
       any look-ahead problems, since
       we limit the interpreted scalar
       to a single line.  If you need
       a multi-line typed sclar, be
       !explicit about the types.

Results:  YAML can encode what ever types
          people need.  And the application
          programmer now has a warning if
          their YAML parser doesn't support
          a particular data type.

With support of types we *will* have 
problems.  The point isn't to mask it
by saying that we are only a "lexer".
Let's support the end-user here.
At first, we can be "dumb" and later
we can get "smarter" without hurting
the data that is already out there.


Best,

Clark       

P.S.  This proposal doesn't require
      a complete "re-write" of the
      specification.