GithubHelp home page GithubHelp logo

yaml's Introduction

yaml's People

Contributors

ingydotnet avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

yaml's Issues

Merging sequences (like Merge keys for mappings)

In #35 a syntax to merge sequences was proposed, but the syntax isn't going to happen, while I can understand that it would be useful to have a standard way of doing this.

There are plans to add programmatic features in YAML 1.3, as @ingydotnet mentioned, but they simply don't exist yet.

The question is, can we come up with something simple, that doesn't introduce new syntax?

Here are some suggestions:

  1. @ingydotnet 's suggestion was:
array1: &my_array_alias
- foo
- bar

array2:
- <: *my_array_alias
- baz
  1. My alternative suggestion would be:
array1: &my_array_alias
- foo
- bar

array2:
- <<
- *my_array_alias
- baz

This approach would be very close to the merge key feature; also when thinking about the implementation (because I have just implemented this in my YAML processor).

  1. Another variant would be almost equal to @ingydotnet's suggestion:
array1: &my_array_alias
- foo
- bar

array2:
- <<: *my_array_alias
- baz

I can't think of a reason not to use the same << as for merge keys.

Typeless Proposal?

Is there a proposal on the table to remove types from YAML? Is the idea to separate the information into two documents such that they both have the same structure, but one gives data and the other type?

Is there a proper Tag URI?

I see that Perl uses tag:yaml.org,2002:perl/. Is that expected/encouraged? Should all global tags use tag:yaml.org,2002:? By contrast, for example, I would have thought Ruby tags should use something like tag:ruby-lang.org,2011/.

YAML 1.2 spec: Example 8.2 incorrect result

Result of the Example 8.2 written in canonical format contains an error in the line 7.

Source:


·→
·detected

Current (wrong) result:

  !!str "\t·detected\n",

As Block Folding declaration says:
In addition, folding does not apply to line breaks surrounding text lines that contain leading white space. Note that such a more-indented line may consist only of such leading white space.

Which mean that the tab preserves the following line feed and the correct result is:

  !!str "\t\ndetected\n",

Merge arrays

As a user, I want to be able to re-use and extend aliased arrays.

Example yaml:

array1: &my_array_alias
  - foo
  - bar

array2:
  << *my_array_alias
  - baz

Expected output:

array1:
  - foo
  - bar

array2:
  - foo
  - bar
  - baz

YAML 1.2 spec: Example 10.9 canonical, syntax error

There is a double quote character missing in the line 7 - "Booleans:

%YAML 1.2

---
!!map {
  !!str "A null" : !!null "null",
  !!str "Also a null" : !!null "",
  !!str "Not a null" : !!str "",
  !!str "Booleans: !!seq [
    !!bool "true", !!bool "True",
    !!bool "false", !!bool "FALSE",
  ],

Block comments.

This is not a dupe for #49.

All I want is some markup that would allow me to comment a whole set of lines with minimal changes. Currently this can be implemented by commenting each line separately, but that means diffs and possible patches become really noisy. I find block comments very useful, specially when experimenting or deprecating config settings.

I don't think C/C++/Java/JS block comments (/* ... */) would be the right syntax (it looks alien), but maybe between #! ... #!? Example:

#! this is the beginning of a block comment.

Block comments are useful for long texts (documentation), disabling big pieces of data (useful on config files) and maybe more

#! this line marks the end of the block comment.

Now that I see it maybe that format is not such a good idea, but I think it's good not to introduce a new syntax element (as it would be the case of a symmetric marker like !#).

Block commenting

It would be great to have a way to comment out a block of consecutive YAML lines. something like python's ''' '''.

Datetime as key

2016-01-01 12:34:56.789: foo
2016-01-02 12:34:56.789: bar

What's the supposed output if you parse that?

I tried a few YAML parser and it was really inconsistent.
Some convert it to a String,
some to the native Date object of the programming language
and some even crashed.

Clarification over serialization process

I don't really understand the scope of "serialization" as it is explained here. Also, see Example 2.10.

I mean, replacing repeated value nodes with ampersands and aliases - what is the gained value of this process?

For a parser, this means more logic and implementation effort, while for a human reader, it seems harder to understand. It is either a short YAML where there are 1-2 duplicated values, so the substitution doesn't make much sense, or a long YAML where this kind of substitution would clearly render it unreadable.

So, if anybody could point out what I'm missing, I would be really grateful. Thanks!

YAML 1.2 spec: Example 8.15 (missing comma)

The canonical YAML does not have a trailing comma (line 7):

%YAML 1.2

---
!!seq [
  !!null "",
  !!str "block node\n",
  !!seq [
    !!str "one"
    !!str "two",
  ],
  !!map {
    ? !!str "one"
    : !!str "two",
  },
]

Is there a way to create new paragraphs in a YAML multi-line key?

I have a YAML key set up like so:

en:
  info: |
    Hello!

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. 

    Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. 

The intended render is:

Hello!

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

However, in reality, this is rendered like so:

Hello! Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

So, my question is: Is it possible to for YAML to be rendered the way I want it to be? Or, do I need to create a separate key for each paragraph?

feature_request(comments): comments inside block notation

1. Summary

It would be nice, if would be possible add comments between lines for block notation.

2. Example

yaml:
  Kira
  # Comment
  Goddess

It would be nice, if this code will be valid.

3. Argumentation

User can have numerous lines, between which it would be nice to place comments. See real example of my YAML file (part of my release-it config):

before:release:
  # [INFO] Commit and push CHANGELOG changes:
  # [INFO] Overwrite master branch from SashaDevelop branch:
  # https://stackoverflow.com/a/2763118/5951529
  # https://github.com/Kristinita/SashaGitHub/commit/016ea890a1f8a7facfb357e2f244c22ee5aff94c
  # [NOTE] Checkout force required, because you can have an error:
  # “error: Your local changes to the following files would be overwritten by checkout”
  # https://stackoverflow.com/a/32556166/5951529
  # [INFO] Use “--no-ff”, that merge with commit:
  # https://ru.stackoverflow.com/a/573773/199934
  git commit -m "Changelog ${version}" &&
  git push origin HEAD &&
  git merge --no-ff --strategy=ours master &&
  git checkout -f master &&
  git merge --no-ff SashaDevelop

Not all comments for line git commit -m "Changelog ${version}" &&, it would be more correct to do so:

before:release:
  # [INFO] Commit and push CHANGELOG changes:
  git commit -m "Changelog ${version}" &&
  git push origin HEAD &&
  # [INFO] Overwrite master branch from SashaDevelop branch:
  # https://stackoverflow.com/a/2763118/5951529
  # https://github.com/Kristinita/SashaGitHub/commit/016ea890a1f8a7facfb357e2f244c22ee5aff94c
  git merge --no-ff --strategy=ours master &&
  # [NOTE] Checkout force required, because you can have an error:
  # “error: Your local changes to the following files would be overwritten by checkout”
  # https://stackoverflow.com/a/32556166/5951529
  git checkout -f master &&
  # [INFO] Use “--no-ff”, that merge with commit:
  # https://ru.stackoverflow.com/a/573773/199934
  git merge --no-ff SashaDevelop

Second variant have a more usability. It comments on specific lines; users will be better understand comments.

Currently, the larger the size of the examples, the more difficult it is for users to understand exactly which lines the comments.

4. Expected behavior

  1. Example from section 2 of this issue is valid YAML.
  2. # Comment line — comment.

5. Current behavior

ERROR:

while parsing a block mapping
  in "<unicode string>", line 1, column 1:
    yaml:
    ^
expected <block end>, but found '<scalar>'
  in "<unicode string>", line 4, column 3:
      Goddess

Thanks.

YAML 1.2 spec: Example 7.1 - the order is inconvenient

The example 7.1 can be improved.
Some parsers (including SnakeYAML) try to keep the order if a map node by default (users may change it).
The example is about Alias and not about order in the map. The canonical YAML can be changed to reflect the same order as in the example.
If the canonical is like this then SnakeYAML can use the canonical YAML in its tests (which is almost always the case):

%YAML 1.2

---
!!map {
  ? !!str "First occurrence"
  : &A !!str "Foo",
  ? !!str "Second occurrence"
  : *A,
  ? !!str "Override anchor"
  : &B !!str "Bar",
  ? !!str "Reuse anchor"
  : *B,
}

YAML.load do not work as expected

irb(main):001:0> require 'yaml'
=> true
irb(main):002:0> YAML.load 'run_on_local_disk: yes'
=> {"run_on_local_disk"=>true}

I want to get this val as yes, do i need to add some option to get my expect result?

Yaml 1.2 - Flow mappngs not a superset of JSON

I'm creating an exact implementation of the Yaml 1.2 spec for a deserializer in F#. The code is not online yet. I've implemented rules 1 - 201, and I'm using rule 207 for testing.

I've noticed differences between spec and intention, I think. My question is about section 7.4.2 Flow Mappings, rule 140 and 141.

[140] c-flow-mapping(n,c) ::= “{” s-separate(n,c)?
ns-s-flow-map-entries(n,in-flow(c))? “}”

[141] ns-s-flow-map-entries(n,c) ::= ns-flow-map-entry(n,c) s-separate(n,c)?
( “,” s-separate(n,c)?
ns-s-flow-map-entries(n,c)? )?

As the examples rightfully demonstrate, you can do this:

{five: six,seven : eight}

{
"adjacent":value,
"readable":·value,
"empty":°
}

What you cannot do with this spec is:

{
···"adjacent":value,
··"readable":·value,
··"empty":°
}

The s-separate(n,c)? (with block-key or flow-key) in both rules 140 and 141, restrict indentation after a line break. I would think that indentation could be acceptable in this case, as yaml is a superset of JSON. Also, on the right side of the spec page, I see Yaml with indented mapping keys. And The reference parser accepts indentation. This is the case for both implicit and explicit mappings.

I've checked my code -which is very close to the spec- several times, but I don't see how the spec allows for indentation at this point. I haven't tested section 7.4.1 yet, but I'd guess it has the same issues.

If I implement this spec, it does allow indents:

[140] c-flow-mapping(n,c) ::= “{” s-separate(n,c)*
ns-s-flow-map-entries(n,in-flow(c))? “}”

[141] ns-s-flow-map-entries(n,c) ::= ns-flow-map-entry(n,c) s-separate(n,c)*
( “,” s-separate(n,c)*
ns-s-flow-map-entries(n,c)? )?

Note that I've only changed s-separate(n,c)? into s-separate(n,c)*.

Specification Revision Changelist

I am implementing a YAML parser and have written it according to the 1.2 spec. I would like to add backwards compatibility for 1.0 and 1.1 as a matter of ensuring maximum interoperability.

I don't much fancy a game of spot the difference right now but I cannot find any authoritative change-lists for the spec revisions, does such a change-list exist?

If not, I can probably generate a difference file for each revision to help identify what was changed.

JSON schema for FLOAT contains NaN, INF

YAML 1.2 says that Float may contain 'three special values (positive and negative infinity, and “not a number”).'
It breaks the JSON compatibility. These values can only be included in the Core schema.

By the way: the example in '10.2.2. Tag Resolution' does not show NaN and INF.

YAML 1.2 spec: Example 10.8 canonical, syntax error

There is a double quote character missing in the line 5 - "Booleans:

%YAML 1.2

---
!!map {
  !!str "A null" : !!null "null",
  !!str "Booleans: !!seq [
    !!bool "true", !!bool "false"
  ],
  !!str "Integers": !!seq [
    !!int "0", !!int "-0",
    !!int "3", !!int "-19"
  ],
  !!str "Floats": !!seq [
    !!float "0.", !!float "-0.0",
    !!float "12e03", !!float "-2E+05"
  ],
  !!str "Invalid": !!seq [
    # Rejected by the schema
    True, Null, 0o7, 0x3A, +12.3,
  ],
}
...

General name for Scalar/Mapping/Sequence?

Is there are general name for the whole idea of representing data in the three fundamental forms of Scalar, Mapping or Sequence?

I am wondering b/c I need to name a few methods that are intended to either return or receive data in these forms. e.g. one of them will be named fu_representation, but what is this "fu"?

logo?

Looking for the logo, preferably in SVG. Closest I could find is this GIF.
I could make into SVG if that's the only one available.

YAML 1.2 spec: 7.3.1. Double-Quoted Style

It says:

In a multi-line double-quoted scalar,
line breaks are are subject to flow line folding,
which discards any trailing white space characters

Typo here: breaks are are subject

Next phrase:

It is also possible to escape the line break character.
In this case, the line break is excluded from the content,
and the trailing white space characters are preserved.

This is obscure. Are trailing spaces the ones before the line breaker, or after?
It might be misleading for those who think that trailing should come after, because trailing(after) spaces must be discarded and leading(before) ones must be preserved.

Next rule:

All leading and trailing white space characters are excluded from the content.

Not quite obvious. leading and trailing could be either for the whole string or for each line.

YAML Document signing and hashing

I have been using YAML for several embedded projects and there have been several use cases where a checksum and/or signature directive would be helpful.

Being able to check data integrity is useful for cases where YAML data is being set over lossy wireless serial connections. In these applications we don't need every message but we need a way to check that each message was valid.

Signing is needed for applications such as IoT enabled radiological sensors where the integrity of data is critical and something similar is already being implement for JSON Web Signatures.

I would love to see any of the following directives implemented. All hashes and signatures were generated for each document from --- to ...\n, including these indicators.

CRC checksum calculated via cksum command

%YAML 1.3
%CRC 2781421733
---
foo: 1
bar: 2
baz: 3
...

Checksum computed by md5sum

%YAML 1.3
%MD5 106a5a4201f0af8d078eacb71338b779
---
foo: 1
bar: 2
baz: 3
...

sha256sum

%YAML 1.3
%SHA256 f4a3d80e6d80b47f909d97936e75b4adc595266093b548d292a715ac2c888c3a
---
foo: 1
bar: 2
baz: 3
...

Signatures can be generated via tools like itsdangerous

%YAML 1.3
%SIG XFwbkYCUxIInwVWdI9fYmbVj3jg
---
foo: 1
bar: 2
baz: 3
...

I'm also OK with other approaches that provide a standard means of signing each YAML document

%YAML 1.3
---
foo: 1
bar: 2
baz: 3
...
# HMAC_SHA256.Z2BCz_ioHPu4J6XpissfpL38N6_0eOR4RwyB5IZu-kY
---
foo: 4
bar: 5
baz: 6
...
# HMAC_SHA256.TKpvn-noboJhfBadb_oH0PJiArCpnt5rCLWEwWbwVNA

HMAC SHA256 can be generated with something like

#!/usr/bin/env python
from itsdangerous import Signer
import hashlib

with open("test.yml") as f:
    data = f.read()
s = Signer('secret',key_derivation = 'hmac', digest_method=hashlib.sha256)
output = s.sign(data)
hmac_sha256 = output.split(".")[-1]
print(hmac_sha256)

Typo in YAML 1.2 spec: Example 8.5

Not really correcting a typo, but bringing more consistency into the example:

-- " # Strip:\n  # Comments:"
++ " # Strip:\n  # comments:"

YAML 1.2 spec: Example 8.19 (canonical YAML is broken)

Example 8.19. Compact Block Mappings

%YAML 1.2

---
!!seq [
  !!map {
     !!str "sun" : !!str "yellow",
  },
  !!map {
    ? !!map {
      ? !!str "earth"
      : !!str "blue"
    },
    : !!map {
      ? !!str "moon"
      : !!str "white"
    },
  }
]

should be changed to

%YAML 1.2

---
!!seq [
  !!map {
     ? !!str "sun" : !!str "yellow",
  },
  !!map {
    ? !!map {
      ? !!str "earth"
      : !!str "blue"
    }
    : !!map {
      ? !!str "moon"
      : !!str "white"
    },
  }
]

(missing ? and redundant ,)

Typo in YAML 1.2 spec: Example 6.27 "Invalid Tag Shorthands"

%TAG !e! tag:example,2000:app/

---
- !e! foo
- !h!bar baz

is what the example says, which is fine. However:

ERROR:
- The !o! handle has no suffix.
- The !h! handle wasn't declared.

The !o! handle is never declared and never used, but it is the !e! handle that has no suffix.

New Core YAML Schema types: Table and Matrix

I would like to suggest new types for the Core YAML Schema: Table and Matrix.

Table

  • Would be helpful in scenarios where we have a lot of objects with the same unordered keys
  • This format could be used for Relational DBMS applications to export and load data using readable text files, instead of the unreadable .csv or .sql files
  • Developers would be really glad to store data files of integration tests using this format and have readable files with clean revision histories

Matrix

  • Would be helpful in scenarios where we have a lot of objects with the same ordered keys
  • Developers could use to store configuration like mapping between roles and resources of an application using spreadsheet softwares that support a file format based on it
  • Spreadsheet softwares could create a new open standard (based on YAML) that could have these advantages:
    • Could be cleaner, using one matrix for data and another with styles references from a styles pallete
    • Could have a clean and readable revision history in version control systems like git
    • Big Spreadsheet files get zipped every time you make a change. When versioning in git (that already have a compression system) you duplicate the size of this file in the revision history every time you change it. It wouldn't happen if we used a text file
    • Have you ever unzipped a .xlsx or .ods file to see how unreadable their XML files are?

Examples

Some examples of how da data would be written in a file (Presentation Model) vs how it would be read by the application (Representation Model).

Applications could use metadata in other fields of the YAML to store information about max column sizes in characters.

Table example:

---
# Use this (Presentation Model):
name: users
content: !!table |
  |      id | name     | type  | gender |
  +---------+----------+-------+--------+
  |       1 / Leonardo | Human | male   |
  |         | M. Carre |       |        |
  |         | iro      /       |        |
  |      10 | Isadora  | Human | female |
  | 2654895 | Princesa | Dog   | female |
  | 2654896 | Pitoco   | Dog   | male   |
---
# To get this (Representation Model):
name: users
content:
  - id: 1
    name: Leonardo M. Carreiro
    type: Human
    gender: male
  - id: 10
    name: Isadora Dias
    type: Human
    gender: female
  - id: 2654895
    name: Princesa
    type: Dog
    gender: female
  - id: 2654896
    name: Pitoco
    type: Dog
    gender: male

Matrix example:

# Use this (Presentation Model):
name: map-resources-to-roles
content: !!matrix |
  |           || admin | moderator | reader |
  +-----------++-------+-----------+--------+
  | list      ||   X   |     X     |    X   |
  | get       ||   X   |     X     |    X   |
  | create    ||   X   |     X     |        |
  | edit      ||   X   |     X     |        |
  | delete    ||   X   |           |        |
---
# To get this (Representation Model):
name: map-resources-to-roles
content:
  - list:
    - admin: X
    - moderator: X
    - reader: X
  - get:
    - admin: X
    - moderator: X
    - reader: X
  - create:
    - admin: X
    - moderator: X
    - reader: ~
  - edit:
    - admin: X
    - moderator: X
    - reader: ~
  - delete:
    - admin: X
    - moderator: ~
    - reader: ~

Matrix example (without keys):

# Use this (Presentation Model):
name: some-matrix-of-weights
content: !!bare-matrix |
  +---+----+---+
  | 4 |  7 | 2 |
  | 9 | 10 | 1 |
  | 7 |  4 | 5 |
---
# To get this (Representation Model):
name: some-matrix-of-weights
content:
  - -  4
    -  7
    -  2
  - -  9
    - 10
    -  1
  - -  7
    -  4
    -  5

Website: link to Syck got hijacked

It has this link: http:// whytheluckystiff.net/syck/

but don't access it, it's some spammy crappy website. If you have edit powers over the site, would you put in a good link there?

Typo in YAML 1.2 spec: Status of this Document

Correct link:

-- Please report errors in this document to the [yaml-core](https://yaml.org/spec/1.2/spec.html) mailing list.
++ Please report errors in this document to the [yaml-core](http://lists.sourceforge.net/lists/listinfo/yaml-core) mailing list.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.