Re: [Yaml-core] paths are strings too? Adding / and that's it.

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

I had a talk with Brian for a short spell:

  - |
   He is ok with the new type family (!) styles:
      !!private
      !yaml-specific
      $domain,year/whatever
      $language/whatever
  - >
   I assume he wants to keep !/whatever reserved for now, 
   pending a discussion of the #DOMAIN proposal.
  - >
   He is ok with just adding '/' to the string regular
   expression, keeping other characters reserved.  This
   is primarly justified by the ypath use case and not by
   a unix path use case, although unix paths would be
   useable unquoted.
  - >
   Since this breaks the //comment special key, he suggested
   that perhaps the # could be used since it is not immediately
   followed by a space.   This works for me:
      --- 
        #: one comment special key
        #more: Another comment special key
  - >
   He's ok with keeping things reserved given the two
   reasons below (flexibility and simplicity).   He's not 
   in favor of adding any more implicit types.
  - >
   Brian brought up the topic of how URIs are handled, 
   does a parser report the tag:uri or not. 

   I answered no, it returns exactly what is in the YAML file
   as these strings themselves should be unique.  One restriction 
   is needed, so that yaml.org,2002 is not used for domain,year 
   which is easy since we control yaml.org ;)

This leaves Brian's big question:

  - Do we need special keys, and if so, how can we clarify
    the specification so that they are used properly.

Overall: >

 I hope this accurately reflects things.  I think it should
 be OK to move ahead with the spec changes, perhaps marking the
 comment special key as "subject to change" and changing it from
 // to # in the short-run.

 That said, I promised to review over the next week or so the 
 special key mechanism, questioning if they are necessary and
 articulating the value they provide (or removing them).

Best,

Clark

On Sat, Aug 10, 2002 at 07:46:49PM -0400, Clark C . Evans wrote:
|
|   I'd like to just add '/' to the string regular expression
|   and keep all other special characters reserved for two reasons:
| 
|     - It gives us flexibility to change stuff in YAML: 2.0
|       (no more changes like this for 1.0)
| 
|     - Having other "special" characters may confuse people
|       as to what is an indicator and what isn't.   Given that
|       # ! * & all mean stuff, it wouldn't be too hard to assume
|       that someone may puzzle if $ % ^ @ mean something special
|       as well.  We can justify / and only / as a 95% usage 
|       rule, but I'd like to keep all the others out.
| 
|   As for "currency", after some soul searching there are three
|   aspects... and none of them should be "implicit"
| 
|   -  Support for fixed point mathematics; in general you don't
|      want to use floating point for currency manipulations but
|      instead want to use integers with very careful watch for
|      rounding/truncation to make sure that you are compliant
|      with any laws that apply.  This is out of YAML's scope, but
|      may be in the scope of a !fixed type which is not part
|      of the core specification.
| 
|   -  Support for units.  I was actually musing that if we hadn't
|      allowed for things that start with a number but arn't a 
|      timestamp, floating, or integer to be a "unit", aka "45 inch"
|      Or "3 foot 2 inch".  Anyway, its too late now, but it was
|      an interesting muse.
| 
|   -  Support for currency.  This is a mix of fixed point plus
|      units.  Since neither of the above are supported in most 
|      languages, it just doesn't make sence to try to bring this
|      into the core of YAML.
| 
|   So, I'm making the above proposal without any hint, suggestion,
|   or underlying motive that $ be reserved for currency later.  I'd
|   just like to exclude all of the other characters for now since
|   I think that they would be confusing and since I don't see a use
|   case for them. 
| 
|   If you wish; we can add both '/' and '$' to the string regex, but
|   I would still like to restrict the other potential indicators for
|   now for the two reasons sited above.
| 
| Best,
| 
| Clark

-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software