## [Yaml-core] Simple Scalar Styles

 [Yaml-core] Simple Scalar Styles From: Oren Ben-Kiki - 2002-06-18 07:34:40 ```Start with "hard facts". We have 6 different places a simple in-line may be used: top-key: top-value - top-seq { inline-key: inline-value } [ inline-seq ] - *Unavoidable* restrictions for each are: possible restrictions: - &SPC Can't start with ' ' - &SEQ Can't start with '- ' - &IND Can't start with ! & * [ ] { } - &KEY Can't contain ': ' - &COM "Can't contain '# '" - &SEP Can't contain ', ' top-value: [ *SPC, *IND, *COM, *SEQ ] top-key: [ *SPC, *IND, *COM, *SEQ, *KEY ] top-seq: [ *SPC, *IND, *COM, *KEY ] inline-key: [ *SPC, *IND, *COM, *KEY ] inline-seq: [ *SPC, *IND, *COM, *SEP ] inline-value: [ *SPC, *IND, *COM, *SEP ] This is 4 different unique combinations: top-value: [ *SPC, *IND, *COM, *SEQ ] top-key: [ *SPC, *IND, *COM, *SEQ, *KEY ] [ top-seq, inline-key ]: [ *SPC, *IND, *COM, *KEY ] [ inline-sep, inline-value ]: [ *SPC, *IND, *COM, *SEP ] Now, up until now, it is all "physics". The above restrictions must be observed to prevent ambiguity. Note that if we simply bite the bullet and go for these four styles, we get the least restrictive syntax, and no ambiguities. Let's call this "option 0". I rather like it myself: - It gives us 6 in-line styles, true, but we already have 6 nested ones, and nobody is complaining. - The 4 simple styles are really one style defined as "DWIM + no ambiguities". Simple to understand. Anyway, there are several restrictions we considered adding: - &INL Can't _contain_ [ ] { } - &SPN Can't span lines. - &WRD Single word (Neil's). # Implies *SPN If option 0 is out of the question, I'd like to suggest the following instead (call this option 1): top-value: [ *SPC, *IND, *COM, *SEQ ] [ top-key, top-seq, inline-key ]: [ *SPC, *IND, *COM, *SEQ, *KEY ] [ inline-sep, inline-value ]: [ *SPC, *IND, *COM, *SEP ] That's just three styles and the only unnecessary restriction is that top-seq and inline-key can't start with '- '. Note that once this merging is done, it make no sense to add *SPN or *WRD to anything (restricting inline-value without also restricting inline-key makes no sense, and restricting inline-key also restricts top-seq, which is definitely a bad idea). I think that option 0 (or option 1) make a lot of sense. Other combinations are possible (for example, something along the lines of Brian's proposal). Please cast them in the above terms so we can compare them sensibly. Have fun, Oren Ben-Kiki ```

 [Yaml-core] Simple Scalar Styles From: Oren Ben-Kiki - 2002-06-18 07:34:40 ```Start with "hard facts". We have 6 different places a simple in-line may be used: top-key: top-value - top-seq { inline-key: inline-value } [ inline-seq ] - *Unavoidable* restrictions for each are: possible restrictions: - &SPC Can't start with ' ' - &SEQ Can't start with '- ' - &IND Can't start with ! & * [ ] { } - &KEY Can't contain ': ' - &COM "Can't contain '# '" - &SEP Can't contain ', ' top-value: [ *SPC, *IND, *COM, *SEQ ] top-key: [ *SPC, *IND, *COM, *SEQ, *KEY ] top-seq: [ *SPC, *IND, *COM, *KEY ] inline-key: [ *SPC, *IND, *COM, *KEY ] inline-seq: [ *SPC, *IND, *COM, *SEP ] inline-value: [ *SPC, *IND, *COM, *SEP ] This is 4 different unique combinations: top-value: [ *SPC, *IND, *COM, *SEQ ] top-key: [ *SPC, *IND, *COM, *SEQ, *KEY ] [ top-seq, inline-key ]: [ *SPC, *IND, *COM, *KEY ] [ inline-sep, inline-value ]: [ *SPC, *IND, *COM, *SEP ] Now, up until now, it is all "physics". The above restrictions must be observed to prevent ambiguity. Note that if we simply bite the bullet and go for these four styles, we get the least restrictive syntax, and no ambiguities. Let's call this "option 0". I rather like it myself: - It gives us 6 in-line styles, true, but we already have 6 nested ones, and nobody is complaining. - The 4 simple styles are really one style defined as "DWIM + no ambiguities". Simple to understand. Anyway, there are several restrictions we considered adding: - &INL Can't _contain_ [ ] { } - &SPN Can't span lines. - &WRD Single word (Neil's). # Implies *SPN If option 0 is out of the question, I'd like to suggest the following instead (call this option 1): top-value: [ *SPC, *IND, *COM, *SEQ ] [ top-key, top-seq, inline-key ]: [ *SPC, *IND, *COM, *SEQ, *KEY ] [ inline-sep, inline-value ]: [ *SPC, *IND, *COM, *SEP ] That's just three styles and the only unnecessary restriction is that top-seq and inline-key can't start with '- '. Note that once this merging is done, it make no sense to add *SPN or *WRD to anything (restricting inline-value without also restricting inline-key makes no sense, and restricting inline-key also restricts top-seq, which is definitely a bad idea). I think that option 0 (or option 1) make a lot of sense. Other combinations are possible (for example, something along the lines of Brian's proposal). Please cast them in the above terms so we can compare them sensibly. Have fun, Oren Ben-Kiki ```
 Re: [Yaml-core] Simple Scalar Styles From: Clark C . Evans - 2002-06-18 12:11:21 ```On Tue, Jun 18, 2002 at 03:36:22AM -0400, Oren Ben-Kiki wrote: | Start with "hard facts". We have 6 different places a simple in-line may be | used: | | top-key: top-value | - top-seq | { inline-key: inline-value } | [ inline-seq ] | | possible restrictions: | - &SPC Can't start with ' ' | - &SEQ Can't start with '- ' | - &IND Can't start with ! & * [ ] { } | - &KEY Can't contain ': ' | - &COM "Can't contain '# '" | - &SEP Can't contain ', ' | - &INL Can't _contain_ [ ] { } | - &SPN Can't span lines. | - &WRD Single word (Neil's). # Implies *SPN My preference... ? [top-key, inline-key, inline-value, inline-seq] : [*SPC, *IND, *COM, *SEQ, *KEY, *SEP, *SPN, *INL } ? [top-value, top-seq] : [*SPC, *IND, *COM, *SEQ, *KEY] And I even think top-value and top-seq qhould be *SPN. | That's just three styles and the only unnecessary restriction is that | top-seq and inline-key can't start with '- '. Note that once this merging is | done, it make no sense to add *SPN or *WRD to anything (restricting | inline-value without also restricting inline-key makes no sense, and | restricting inline-key also restricts top-seq, which is definitely a bad | idea). Perhaps, but for the case of keys and in-line stuff I'm not all that happy with things continuing on multiple lines (except for the containers themselves). I can live with it... but IMHO, it is ugly. Clark ```
 Re: [Yaml-core] Simple Scalar Styles From: Brian Ingerson - 2002-06-18 15:11:23 ```On 18/06/02 03:36 -0400, Oren Ben-Kiki wrote: > Start with "hard facts". We have 6 different places a simple in-line may be > used: > > top-key: top-value > - top-seq > { inline-key: inline-value } > [ inline-seq ] > > - *Unavoidable* restrictions for each are: > > possible restrictions: > - &SPC Can't start with ' ' > - &SEQ Can't start with '- ' > - &IND Can't start with ! & * [ ] { } > - &KEY Can't contain ': ' > - &COM "Can't contain '# '" > - &SEP Can't contain ', ' > > Anyway, there are several restrictions we considered adding: > - &INL Can't _contain_ [ ] { } > - &SPN Can't span lines. > - &WRD Single word (Neil's). # Implies *SPN If you add the restriction we've be using all along: - &A_N Must start with A-Za-z0-9_ # implies *SPC *IND *SEQ Then the proposals become clearer: Option 0: top-value: [ *A_N, *COM ] top-key: [ *A_N, *COM, *KEY ] [ top-seq, inline-key ]: [ *A_N, *COM, *KEY ] [ inline-sep, inline-value ]: [ *A_N, *COM, *SEP ] > If option 0 is out of the question, I'd like to suggest the following > instead (call this option 1): top-value: [ *A_N, *COM ] [ top-key, top-seq, inline-key ]: [ *A_N, *COM, *KEY ] [ inline-sep, inline-value ]: [ *A_N, *COM, *SEP ] Cheers, Brian ```