YAML Ain't Markup Language

On Saturday 01 May 2004 20:34, Blue Prawn wrote:
> Hi,
>
> When it is not possible at all to indent one line, is it possible to escape
> this in a way?

Axiom: "The double quoted style *always* works".

In your case, like this:

	---
	Here is an email writen in Yaml:
	- giving a first url: http://yaml.org/
	- ginving another url: 
	 "http://www.another-url.org/this_link_is_far\
	 _too_long_for_mail_client_to_allow_spaces\
	 .html" # and cutting this line would broke the link
	---

Admittedly, not the most readable presentation. Then again, if you have such a 
long line, no presentation will be very readable anyway.

Have fun,

	Oren Ben-Kiki

On Sat, May 01, 2004 at 07:34:41PM +0200, Blue Prawn wrote:
| ---
| Here is an email writen in Yaml:
|   - giving a first url: http://yaml.org/
|   - ginving another url: \
| http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html
| # and cutting this line would broke the link

In cases like this I often use the double quoted style,

   zoom: "http://www.another-url.org/this_link_is_far\
          too_long_for_mail_client_to_allow_spaces.html"

The problem, of course, with this style is that one would have
to escape intermediate characters.

| Or another one closer to heredoc which perl and php are used to:
|   - ginving another url: |<<
| http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_allow_spaces.html
| # and cutting this line would broke the link
| <<

This is our most frequently proposed feature.  I suppose that it
isn't any more ugly than double quoted strings...  Brian/Oren?

Clark

On Saturday 01 May 2004 21:05, Clark C. Evans wrote:
> | Or another one closer to heredoc which perl and php are used to:
> |   - ginving another url: |<<
> | http://www.another-url.org/this_link_is_far_too_long_for_mail_client_to_a
> |llow_spaces.html # and cutting this line would broke the link
> | <<
>
> This is our most frequently proposed feature.  I suppose that it
> isn't any more ugly than double quoted strings...  Brian/Oren?

We have considered this, at one time. You can have the same effect by using an 
indented literal scalar. The benefit of the "terminated" style is that you 
don't need to indent the scalar. From a YAML point of view, that's a 
disadvantage; the document structure becomes much less visible.

It almost seems as though this should be a flow style rather than a block 
style, since it uses a marker rather than indentation to denote structure. 
The following doesn't make much sense, though:

	---
	some:
		flow: { terminated: <<EOF
	Text
	EOF}
	...

Perhaps if someone comes up with a use case where indenting the text is a 
problem? The problem isn't long lines (for these, you need to use double 
quotes anyway). Admittedly, indenting literal scalars costs screen real 
estate, but they have to be pretty deeply nested for this to make a real 
difference (you can indent each level by just one space if you want).

What's the use case?

Have fun,

	Oren Ben-Kiki

The use case was to allow a file to be 'embedded' in YAML.  However,
this is quite easy with sed, so there really isn't a need for this
construct.

$ sed 's/^/  /' embedd.txt >> file.yaml

;) Clark

On Sat, May 01, 2004 at 09:30:19PM +0300, Oren Ben-Kiki wrote:
| > | Or another one closer to heredoc which perl and php are used to:
| > |   - ginving another url: |<<
| > | http://www.another-url.org/this_link_is_far_too_long_...
| > | <<
| >
| > This is our most frequently proposed feature.  I suppose that it
| > isn't any more ugly than double quoted strings...  Brian/Oren?

| We have considered this, at one time. You can have the same effect by
| using an indented literal scalar. The benefit of the "terminated" style
| is that you don't need to indent the scalar. From a YAML point of view,
| that's a disadvantage; the document structure becomes much less visible.
| 
| It almost seems as though this should be a flow style rather than a
| block style, since it uses a marker rather than indentation to denote
| structure. The following doesn't make much sense, though:
| 
| 	---
| 	some:
| 		flow: { terminated: <<EOF
| 	Text
| 	EOF}
| 	...
| 
| Perhaps if someone comes up with a use case where indenting the text is
| a problem? The problem isn't long lines (for these, you need to use
| double quotes anyway). Admittedly, indenting literal scalars costs
| screen real estate, but they have to be pretty deeply nested for this to
| make a real difference (you can indent each level by just one space if
| you want).

> What's the use case?

The one I said, giving an url in a mail writen in yaml.
If you put just only one space at the begining of this line, the mail client 
will put a linebreak after this space and then the url is not indented, so it 
is impossible to indent a very long link in an email.
And if you cut the link it will hardly break it !
I know it is possible to change the parameters of the mail clients, but it not 
a good idea to remove it definitively. And remove it just to write an email 
is quite boring, isn't it?

---
bookmarks:
  - http://yaml.org/
  - { <<EOB
http://grincheux.codelutin.org/~monnier/wallpapers/debian/debian_C01c.png
  EOB}
...

Then the question is, is it important to permit to write emails in yaml?
If you cut the link, a parser will glue it back, but humans?

On Sat, May 01, 2004 at 11:36:42AM +0300, Oren Ben-Kiki wrote:
| Proposal 1: Relax the seperation spaces to allow line-spanning in block 
| context.
...
| This simplifies the rules (and, of course, the productions).

I'm all for simplifying rules.  If it doesn't introduce problems,
then this is just fine.

| Proposal 2: Use Brian's "implicit header" rule combined with proposal 1, to 
| allow properties without a header (directives do require a header because 
| they must be in the same line with it).

  Is there a reason why directives need to start on the same line,
  I mean, if we are allowing for multiple line spanning for 'modifiers',
  perhaps the productions should allow:

     --- %one:two
         %three:four

   etc.

| In fact, if we just use Brian's implicit header rule, we could trivially allow 
| header-less top-level scalar nodes. That would further simplify the rule (and 
| the productions :-)

Ok.  I'm all for simplifying productions!

| Proposal 3: Proposal 2, plus removing the (now arbitrary) restrictions that 
| top-level nodes may not be scalars.

I think a top level quoted scalar makes sense, but I'm still
a bit worried about allowing "unadorned" scalars.

Clark

On Saturday 01 May 2004 19:41, Clark C. Evans wrote:
> | Proposal 1: Relax the seperation spaces to allow line-spanning in block
> | context.
>
> I'm all for simplifying rules.  If it doesn't introduce problems,
> then this is just fine.

Yay! (Kills a few pesky productions).

> | Proposal 2: Use Brian's "implicit header" rule combined with proposal 1,
> | to allow properties without a header (directives do require a header
> | because they must be in the same line with it).
>
>   Is there a reason why directives need to start on the same line,
>   I mean, if we are allowing for multiple line spanning for 'modifiers',
>   perhaps the productions should allow:
>
>      --- %one:two
>          %three:four
>
>    etc.

Hmmm. Not really. This touches the question of whether it is valid to write:

	<SOF>
	%one:two
	!seq
	- entry
	<EOF>

If we allow spanning for directives, the above becomes valid. I don't feel 
that strongly about this. Currently we only have one directive so it is 
rather academic. I'll go with whatever you/Brian think is best here.

> | Proposal 3: Proposal 2, plus removing the (now arbitrary) restrictions
> | that top-level nodes may not be scalars.
>
> I think a top level quoted scalar makes sense, but I'm still
> a bit worried about allowing "unadorned" scalars.

Point taken. Then again, it seems silly to go out of our way to forbid 
something that otherwise "just works" (both rules-wise and 
implementation-wise).

Have fun,

	Oren Ben-Kiki

On Sat, May 01, 2004 at 08:57:01PM +0300, Oren Ben-Kiki wrote:
| >   Is there a reason why directives need to start on the same line,
| >   I mean, if we are allowing for multiple line spanning for 'modifiers',
| >   perhaps the productions should allow:
| >
| >      --- %one:two
| >          %three:four
| >
| >    etc.
| 
| Hmmm. Not really. This touches the question of whether it is valid to write:
| 
| 	<SOF>
| 	%one:two
| 	!seq
| 	- entry
| 	<EOF>
| 
| If we allow spanning for directives, the above becomes valid. I don't feel 
| that strongly about this. Currently we only have one directive so it is 
| rather academic. I'll go with whatever you/Brian think is best here.

Well, if the productions are simpler, by all means.

| > | Proposal 3: Proposal 2, plus removing the (now arbitrary) restrictions
| > | that top-level nodes may not be scalars.
| >
| > I think a top level quoted scalar makes sense, but I'm still
| > a bit worried about allowing "unadorned" scalars.
| 
| Point taken. Then again, it seems silly to go out of our way to forbid 
| something that otherwise "just works" (both rules-wise and 
| implementation-wise).

I acquiesce.  Simpler productions and implementations are good things.

Clark