Skip to content
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

Per-line and stream based conversion formatting #271

Closed
goodmami opened this issue Jan 15, 2020 · 1 comment
Closed

Per-line and stream based conversion formatting #271

goodmami opened this issue Jan 15, 2020 · 1 comment
Milestone

Comments

@goodmami
Copy link
Member

When converting semantic representations with delphin convert, the default method has no intra-representation indentation but each representation is separated by a newline. Formats with header and footer elements, such as XML and JSON, always include these elements. This behavior is changed with the --indent option as follows:

  • --indent 0 : same as default, I think
  • --indent (no value) : default indentation for the codec
  • --indent N where N > 0 : insert newlines where appropriate and indent N spaces if the format allows it

There are at least 2 potentially useful alternatives that are not accessible:

  • no newlines at all (a single stream)
  • no header or footer

The problem with adding a single option for these (e.g., --stream and --lines) is that it isn't clear if that's for writing or for reading. I don't think it matters much for the former, but the latter will currently break for XML and JSON if the root elements are not there. If the codecs were robust to the absence of a root element then the options could pertain only to writing.

@goodmami
Copy link
Member Author

Maybe an easier way to deal with this is to allow a suffix on a codec name like -lines (e.g., dmrsjson-lines) which assumes each line is a full representation. For streaming, I can either change the default behavior so no newlines are printed if --indent is not given, or allow a special option like --indent=no. I'm concerned that the former might annoy some people or be considered a break in backward compatibility.

goodmami added a commit that referenced this issue Jan 15, 2020
@goodmami goodmami added this to the v1.2.0 milestone Jan 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant