headers
Oren Ben-Kiki | 1 May 2004 01:12
Gravatar

Re: Re: spec suggestions

On Friday 30 April 2004 18:30, Alexis Layton wrote:
> > I hope this helps.  Do you have any suggestions for improving the
> > documentation so that this is more clear?
>
> I've been following the development of the YAML spec on and off for some
> time,
> and the one thing I wish the document could contain are either (a) change
> bars,
> or (b) descriptions of what's changed since the last published version.
>
> There is no meta-commentary in the spec document at all.

We maintain a "changes.html" file which lists all changes back to the very 
first few drafts. You can find it in http://www.yaml.org/spec/changes.html. 
It makes for interesting reading if you want to trace the "history of YAML". 

Have fun,

	Oren Ben-Kiki

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Permalink | Reply | 0 comments |
headers
Oren Ben-Kiki | 1 May 2004 10:36
Gravatar

Seperation Spaces

I'm in the process of going over all the productions and writing annotated 
examples (marking up which part of the text matches the demonstrated 
production). It is amazing how many subtle issues surface when you do that...

For example, seperation spaces. Currently, this is valid:

	---
	flow value:
	    !str
	      &anchor
	 "text"
	...

But this isn't:

	---
	block value:
	  !str
	    &anchor
	      |
	 This literal is indented
	 by a single space.
	...

Technically (production-wise), there's a "seperation-spaces" production that 
is currently limited to a single line in block context but not in flow 
context. There's really no good reason for this, but I don't recall that we 
ever discussed this.

Is it useful? Well, being able to wrap long lines is useful for better
(Continue reading)

Permalink | Reply | 502 comments |
headers
Clark C. Evans | 1 May 2004 18:41
Gravatar

Re: Seperation Spaces

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.
(Continue reading)

Permalink | Reply | 502 comments |
headers
Blue Prawn | 1 May 2004 19:34

indent escape?

Hi,

When it is not possible at all to indent one line, is it possible to escape 
this in a way?

---
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
---
Or perhaps another syntax:
  - 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
  ||
---
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 SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
(Continue reading)

Permalink | Reply | 15 comments |
headers
Oren Ben-Kiki | 1 May 2004 19:43
Gravatar

Re: indent escape?

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

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oren Ben-Kiki | 1 May 2004 19:57
Gravatar

Re: Seperation Spaces

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>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Clark C. Evans | 1 May 2004 20:05
Gravatar

Re: indent escape?

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

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Clark C. Evans | 1 May 2004 20:14
Gravatar

Re: Seperation Spaces

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.
|
(Continue reading)

Permalink | Reply | 2 comments |
headers
Oren Ben-Kiki | 1 May 2004 20:30
Gravatar

Re: indent escape?

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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Clark C. Evans | 1 May 2004 22:14
Gravatar

Re: indent escape?

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane