New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from XML to S-Expressions file format #192

Closed
ubruhin opened this Issue Oct 17, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@ubruhin
Member

ubruhin commented Oct 17, 2017

In #150 we decided to switch from XML to S-Expressions as primary file format. This issue can be used for discussions about the details of the new file format.

I already have a first question to discuss: When should S-Expression values be quoted and when not?

According to this IETF draft, double quotes can optionally be omitted if the value does not contain strings. So following two lines are considered as equivalent:

(key value)
(key "value")

But IMO it would be better to always use double quotes if the represented value is a string, and omit the quotes only if the represented type is a boolean or number. Examples:

(number -12.34)
(boolean true)
(string "foobar")

This way one can "see" the data type of the values in an S-Expressions file. This makes it also easier to support syntax highlighting in editors, because the syntax highlighter can distinguish between strings, numbers and booleans. This is how syntax highlighting could look like for our files:

auswahl_015

Actually we can even go one step further: Should we define a set of basic data types used in S-Expression files? For example:

  • Integer: A number without decimal point (e.g. -42)
  • Float: A number with decimal point (e.g. -42.0)
  • Boolean: Either true or false
  • Enum item: A string without spaces, but not true or false (e.g. align_top)
  • String: A string in double quotes (e.g. "Hello World!")

A syntax highlighter could then easily distinguish between all of these data types, so a LibrePCB S-Expressions file would look really nice in editors ;) In addition, such a file is even more expressive because the data type of every value is visible, like this:

auswahl_014

@ubruhin ubruhin added the enhancement label Oct 17, 2017

@ubruhin ubruhin added this to the 0.1 milestone Oct 17, 2017

@ubruhin ubruhin self-assigned this Oct 17, 2017

@dbrgn

This comment has been minimized.

Show comment
Hide comment
@dbrgn

dbrgn Oct 17, 2017

Contributor

But IMO it would be better to always use double quotes if the represented value is a string, and omit the quotes only if the represented type is a boolean or number.

Agree!

Should we define a set of basic data types used in S-Expression files?

Yes! I like your suggestions so far. With the "enum item" type we'll definitely be non-standard, but sexprs aren't really standardized anyways.

Contributor

dbrgn commented Oct 17, 2017

But IMO it would be better to always use double quotes if the represented value is a string, and omit the quotes only if the represented type is a boolean or number.

Agree!

Should we define a set of basic data types used in S-Expression files?

Yes! I like your suggestions so far. With the "enum item" type we'll definitely be non-standard, but sexprs aren't really standardized anyways.

@dbrgn

This comment has been minimized.

Show comment
Hide comment
@dbrgn

dbrgn Oct 17, 2017

Contributor

Ah, actually the IETF draft differentiates between quoted strings and tokens. Maybe we could try to fully implement that standard?

Contributor

dbrgn commented Oct 17, 2017

Ah, actually the IETF draft differentiates between quoted strings and tokens. Maybe we could try to fully implement that standard?

@ubruhin

This comment has been minimized.

Show comment
Hide comment
@ubruhin

ubruhin Oct 17, 2017

Member

With the "enum item" type we'll definitely be non-standard

I think the enum type is allowed according the IETF draft, they call such strings "token".

But it seems that the non-quoted numbers are not allowed, because a token must not start with a digit :( But KiCad also does not quote numbers, so LibrePCB would not be the only non-"standard"-conform application xD

Member

ubruhin commented Oct 17, 2017

With the "enum item" type we'll definitely be non-standard

I think the enum type is allowed according the IETF draft, they call such strings "token".

But it seems that the non-quoted numbers are not allowed, because a token must not start with a digit :( But KiCad also does not quote numbers, so LibrePCB would not be the only non-"standard"-conform application xD

@dbrgn

This comment has been minimized.

Show comment
Hide comment
@dbrgn

dbrgn Oct 17, 2017

Contributor

True, seems that the standard does not include non-quoted numeric types.

Contributor

dbrgn commented Oct 17, 2017

True, seems that the standard does not include non-quoted numeric types.

@ubruhin

This comment has been minimized.

Show comment
Hide comment
@ubruhin

ubruhin Oct 20, 2017

Member

Another very important question: What file extension should we use for our S-Expression files?

  • *.sexp or *.sexpr: If we believe that some time S-Expressions become more popular and thus editors automatically recognize this file extension and enable syntax highlighting ;) But I think this is "dangerous" as long as there is no official, stable file format specifications because if some time there are official specs available, our files may not be standard conform.
  • *.sexp or *.sexpr: As described above, but with the difference that instead of waiting for official specifications, we could write them by ourselves 😄 But no time for that, so forget it...
  • *.sexp or *.sexpr: As described above, but don't care about future official specifications ;)
  • *.lpf (LibrePcb File): Quite short, probably already used by other applications?
  • *.lpcb (LibrePCB): Maybe looks like it's a PCB file (even if it could be a schematic or something else)?
  • *.lpcbf (LibrePCB File): Looks ugly? ;)
  • *.lpse (LibrePcb S-Expressions): ?
  • *.librepcb: Too long?
  • Something else?

@dbrgn @rnestler Any opinions?

Member

ubruhin commented Oct 20, 2017

Another very important question: What file extension should we use for our S-Expression files?

  • *.sexp or *.sexpr: If we believe that some time S-Expressions become more popular and thus editors automatically recognize this file extension and enable syntax highlighting ;) But I think this is "dangerous" as long as there is no official, stable file format specifications because if some time there are official specs available, our files may not be standard conform.
  • *.sexp or *.sexpr: As described above, but with the difference that instead of waiting for official specifications, we could write them by ourselves 😄 But no time for that, so forget it...
  • *.sexp or *.sexpr: As described above, but don't care about future official specifications ;)
  • *.lpf (LibrePcb File): Quite short, probably already used by other applications?
  • *.lpcb (LibrePCB): Maybe looks like it's a PCB file (even if it could be a schematic or something else)?
  • *.lpcbf (LibrePCB File): Looks ugly? ;)
  • *.lpse (LibrePcb S-Expressions): ?
  • *.librepcb: Too long?
  • Something else?

@dbrgn @rnestler Any opinions?

@dbrgn

This comment has been minimized.

Show comment
Hide comment
@dbrgn

dbrgn Oct 21, 2017

Contributor

What about .lp? Is that already used? (Edit: See this. Don't think we need to care.)

Contributor

dbrgn commented Oct 21, 2017

What about .lp? Is that already used? (Edit: See this. Don't think we need to care.)

@dbrgn

This comment has been minimized.

Show comment
Hide comment
@dbrgn

dbrgn Oct 21, 2017

Contributor

The .sexp extension could in theory be problematic behind company or school firewalls that are a bit eager on content filtering. As an alternative, you could use .se.

Contributor

dbrgn commented Oct 21, 2017

The .sexp extension could in theory be problematic behind company or school firewalls that are a bit eager on content filtering. As an alternative, you could use .se.

@ubruhin

This comment has been minimized.

Show comment
Hide comment
@ubruhin

ubruhin Oct 21, 2017

Member

What about .lp?

I like that! 😃 So far my favorites are .lp and .lpcb.

Member

ubruhin commented Oct 21, 2017

What about .lp?

I like that! 😃 So far my favorites are .lp and .lpcb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment