Update the attributes syntax

- We've never done most of what we agreed to do.

- We argued out a few points in #77 that we should capture

    1.  we decided that functional arguments foo("bar", "baz") are
        better than method chaining, and this was incorporated into
        the Chef 12 attributes updates.

    2.  we decided on strings over symbols in the arguments.

    3.  we also decided that RFC #18 needed to be amended because
        the implications of foo("bar.baz") were poor.

- This also argues for the addition of an option (-F offhand blindly
  copied from awk, dunno if that'll really work) to deal with
  cases where '.' as a field separator causes issues -- because typing
  arrays on the command line is incredibly poor UX and nobody has
  bothered to implement it.

- This officially demotes the dot-syntax to a commandline workaround,
  and pushes *argv style / array formatting to the forefront for
  ruby APIs.

rfc018-attribute-syntax.md

@@ -11,19 +11,32 @@ Chef-Version: 12
 This RFC defines the syntax for accessing deeply nested keys inside
 the node attribute structure.
 
-When attributes are referred to as strings inside Ruby code or on the
-command line, a dot(".") should be used as the key separator:
+The preferred shape of APIs that refer to attributes is functional
+notation where the arguments are expressed as strings.  APIs which
+only implement this pattern are acceptable.
 
-   - "key1.key2"
-   - knife node show foo -a key1.key2
+   - get("foo", "bar", "baz")
+   - set("foo", "bar", "baz", value)
+
+The method chaining syntax is also fully supported, although discouraged
+for new APIs.  APIs which only implement this pattern are acceptable.
+
+   - node['foo', 'bar', 'baz']
+   - node['foo', 'bar', 'baz'] = value
+
+In order to support command line usage, it is acceptable to use dots
+as a field separator:
+
+   - knife node show mynode -a foo.bar
 
 Additionally, in order to avoid escaping for keys that might contain
-"." the following array syntax should also be supported:
+"." it should be possible to pass a user-defined field separator key:
 
-   - ['key1', 'key2']
-   - knife node show foo -a "['key1', 'key2']"
+   - knife node show mynode -F: -a foo:bar 
 
-When the array syntax is used "." has no special meaning.
+The use of command line syntax in ruby code which can use one of the
+prior two formats is discouraged.  The use of the field separator is
+only used when the ruby API versions of the call would be awkward.
 
 ## Specification
 
@@ -34,62 +47,53 @@ been called out.
 ### Command-line access (knife)
 
 When specifying attributes on the command line, "." should be the
-key separator.  Alternatively, an array can be provided:
+default key separator.
 
 ```
 knife node show foo -a key1.key2
-knife node show foo -a "['key1', 'key2']"
+knife node show foo -F: key1:key2
 ```
+
 ### Command-line access (other)
 
 *Requires Change* All other Chef-maintained tools should also use
 dot-separated strings and arrays to specify not attributes, including Ohai:
 
 ```
 ohai cpu.real
-ohai "['cpu', 'real']"
+ohai -F: cpu:real
 ```
 
 Documentation for 3rd-party tool writers should encourage the use of
 these formats as well.
 
 ### Search Syntax
 
-*Requires Change* Chef search should support "." as the record separator:
-
-```
-search(:node, "key1.key2:4")
-```
+*Requires Change* Chef search should support using the functional `*args`
+notation:
 
 ```
-knife search node "key1.key2:4"
+search(:node, "key1", "key2", "4")
 ```
 
-For backward compatibility, "_" should should be supported as
-well through Chef 12.
+Knife search should suport the -F notation on the command line:
 
 ```
-knife search node "key1_key2:4"
+knife search node -F; "key1;key2:4"
 ```
 
-### Partial Search Syntax
-
-*Requires Change*
+For backward compatibility, `"_"` should should be supported as
+well through Chef 13.
 
-Search filters currently only supports the array syntax.  Dot-separated strings
 ```
-partial_search(:node, 'role:web', keys => { 'name' => [ 'name' ],
-                                            'kernel_version' => 'kernel.version' })
-
-search(:node, 'role:web', :filter_result { 'kernel_version' => 'kernel.version'})
+knife search node "key1_key2:4"
 ```
 
 ### Attribute Whitelisting
 
 *Requires Change*
 
 ```
-normal_attribute_whitelist = ['network.interfaces', 'fqdn']
 normal_attribute_whitelist = [['network', 'interfaces'], 'fqdn']
 ```
 
@@ -100,7 +104,7 @@ Currently, "/" is used as the attribute separator.
 *Requires Change*
 
 ```
-provides "network.interfaces"
+provides("network", "interfaces")
 ```
 
 Currently, Ohai 7 "provides" and "requires" statements use "/" as the attribute separator.
@@ -116,20 +120,15 @@ interpret the "." as the record separator.  Namely,
 
 #### Conflicts
 
-Some users may want to use "." in their key names.  This poses a
-problem when a conflict exists.  For example:
+Since some users may want to use '.' in their key names the use of the
+'.' syntax in ruby code is discouraged to avoid conflicts.  For example:
 
 ```
 node['key1.key2'] = "foo"
 node['key1']['key2'] = "bar"
 ```
 
-When Chef tools encounter the attribute specification 'key1.key2' the
-deeply nested key will be preferred. Thus, given the above example
-'key1.key2' would refer to the attribute with the value "bar".
-
-The array syntax should be used in cases when the user needs to
-explicitly avoid the interpretation of ".".
+Ruby APIs shall not be required to implement the dot syntax to avoid that ambiguity.
 
 # Motivation