Re: [Yaml-core] Plain scalar fixes for YAML 1.2

[Kirill S. <xi...@ga...>]

On Wed, Mar 29, 2006 at 07:17:34PM -0500, Clark C. Evans wrote:
> On Thu, Mar 30, 2006 at 01:29:30AM +0300, Kirill Simonov wrote:
> | > The Color Problem
> | > -----------------
> | > 
> | > I think including color specifications, unquoted, is a valid use-case
> | > for YAML:  ``#c0c0c0`` should be valid plain scalar. Unfortunately, its
> | > competing use-case is the first-line pound-sign comment #!/some/program
> | > as well as #------- dividers.  Hence the current compromise is to forbid
> | > " #" in a plain scalar.  What do we think about this rule instead:
> | > 
> | >   1. Forbid " # " in plain scalars, allowing end-of-line comments,
> | >      but permitting the color example above.
> | > 
> | >   2. Allow "#xxx" content only if it it is preceded by whitespace,
>                       ^ comments
> | >      hence sparing content dividers and first-line #! shell markers.
> | 
> | This rule breaks the invariant that you may take any yaml fragment, add
> | (or remove) any number of indentation spaces and it still retains its
> | meaning.
> | 
> | Besides I think comments
> |     #of 
> |     #this
> |     #kind
> | should be allowed.
> 
> I think I had a typo; does this change your assessment?  In both cases,
> the comment like #this would be preceded by whitespace, so they would
> be acceptable.

But then
    color: #c0c0c0
will become an empty scalar followed by a comment, right? It seems to me
that your correction takes you back to the YAML-1.1 comment rules.

> | >   4. Remove the ": " restriction from plain-scalars in regular
> | >      indented styles, hence permitting the unambiguous title example.
> | 
> | I don't think it's possible to remove this restriction. How could you
> | parse
> |     plain key: any value
> | then?
> 
> We already have a special case for keys; that would remain, I think.
> I was referring to the plain scalars in - lists, in structured keys,
> and in the value of a key.

It will not work for '-' lists and structured keys because of inline
block styles. For instance, the document

    ? key: value
    : - key: value

is a valid representation of

    { ? {key: value} : [ {key: value} ] }


Consider four documents:

---
title: Hanna Reitsch: Hitler's Female Test Pilot
---
title:
    Hanna Reitsch: Hitler's Female Test Pilot
---
? title
: Hanna Reitsch: Hitler's Female Test Pilot
---
titles:
- Hanna Reitsch: Hitler's Female Test Pilot

According to the YAML-1.1 specs, the first document is ill-formed while
the others contain the mapping
    { ? Hanna Reitsch : Hitler's Female Test Pilot }
You can only fix the interpretation of the first document, but I don't
think it's a good idea. It would be confusing if the documents

    ---
    title: Hanna Reitsch: Hitler's Female Test Pilot
    ---
    title:
        Hanna Reitsch: Hitler's Female Test Pilot

had such radically different meanings.


As Brad suggested, this problem can be easily fixed using quotes or
block scalars:

---
title: "Hanna Reitsch: Hitler's Female Test Pilot"
---
title: >-
    Hanna Reitsch: Hitler's Female Test Pilot



I support your other suggestions about forbidding ':' for plain scalars
in the flow context and making tab rules less restrictive.



-- 
xi