Skip to content
Draft
Changes from all commits
Commits
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
8 changes: 8 additions & 0 deletions docs/specification/value-types.md
Original file line number Diff line number Diff line change
Expand Up @@ -255,10 +255,18 @@ For example "one part flour two parts sugar" is acceptable.
A composition represented as a map from the component name to the quantity.
The quantities do not express an uncertainty, but also do not imply that there is absolute certainty in their values.

<<<<<<< HEAD
Field name | Value type | Default | Description
----------------|------------|---------|-----------
`type` | String | Req. | "nominal\_composition"
`quantities` | Map[String, Number]| Empty set | | Map[String, Number]
`basis` | `mass`, `volume`, `number`, `unknown` | `unknown` | The type of measurement that informed the quantity
Copy link
Contributor

Choose a reason for hiding this comment

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

What about "other"? I'm thinking about some of the exotic formulations use cases like dry basis.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Dry basis is still a mass (or molar or volume) basis. Compositions are not guaranteed to be normalized, so a user filter or Attribute Template could meet that need.

More complex expressions like molarity are so complex that explicit attributes are probably the only reasonable solution.

=======
| Field name | Value type | Description |
|--------------|---------------------|------------------------|
| `type` | String | "nominal\_composition" |
| `quantities` | Map[String, Number] | Map[String, Number] |
>>>>>>> master

##### Constraints

Expand Down