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.

Sign up for GitHub

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

Output Formatting #679

Merged
merged 14 commits into from
Dec 28, 2018
Merged

Output Formatting #679

Changes from 1 commit
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
cc8957f
Add 'output formatting' markdown composition as working medium
gregsdennis Nov 18, 2018
2a4b28b
Add exceedingly large verbose output as separate file
gregsdennis Nov 18, 2018
6571b06
Add composition to spec XML
gregsdennis Nov 18, 2018
59f9ff0
updated per @Anthropic's suggestions :+1:
gregsdennis Nov 30, 2018
cf7a6e0
addressed most of @handrews's comments
gregsdennis Dec 5, 2018
fd1b00d
removed composition file; added output schema
gregsdennis Dec 6, 2018
df63510
clarified requirements around implementation support
gregsdennis Dec 7, 2018
06cd268
addressed some wording concerns
gregsdennis Dec 7, 2018
5504ffc
added comment for relative pointers in output formatting
gregsdennis Dec 10, 2018
32c624b
Updated language around format support requirements
gregsdennis Dec 18, 2018
fb312cc
Set support requirements per conversation in slack
gregsdennis Dec 21, 2018
02295dc
better wording for output
gregsdennis Dec 25, 2018
063fbe2
a bit more wordsmithing around output requirements
gregsdennis Dec 27, 2018
235c54a
Merge branch 'master' into draft-08-output-formatting
handrews Dec 28, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 3 additions & 6 deletions jsonschema-core.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2142,12 +2142,9 @@
structure that matches the exact structure of the schema.
</t>
</list>
Implementations MUST provide support for the "flag" format. It is RECOMMENDED
that implementations support at least one of the complex formats as well. Each
format is independent of the others. For example, if an implementation decides
to support the "detailed" format, it is not also required to support the "basic"
or "verbose" formats, and vice versa. Implementations SHOULD specify in their
documentation which formats of validation they support.
Implementations MUST provide support for the "flag" format and SHOULD provide the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Early on, we were going to avoid MUST requirements, on the grounds that implementations can take many forms, including those with extreme memory constraints, or streaming implementations, or other things we can't anticipate where there may be a pretty compelling reason for just a boolean rather than an object. I'm a little hesitant to use MUST here, although I understand the desire for interoperability

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could support an approach where we say that implementations SHOULD support one or more of these formats, and if they do, then they MUST support flag, SHOULD support basic, etc.

That leaves some wiggle room for implementations that may be working under constraints that we cannot anticipate.

"basic" and "detailed" formats. The "verbose" format is OPTIONAL. Implementations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd use

"flag" format, SHOULD provide the "basic" and "detailed" formats, and MAY provide the "verbose" format.

because we use MAY a lot in these documents, but rarely if ever use OPTIONAL. I don't think there's any reason, it just seems to be the convention that has developed organically.

I don't feel strongly about this, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I was sure there was a way to make it smoother.

SHOULD specify in their documentation which formats of validation they support.
</t>

</section>
Expand Down