diff --git a/documents/Specification/MaterialX.Proposals.md b/documents/Specification/MaterialX.Proposals.md
index 4548bda33a..e95c9aa3bc 100644
--- a/documents/Specification/MaterialX.Proposals.md
+++ b/documents/Specification/MaterialX.Proposals.md
@@ -157,6 +157,207 @@ Materials can inherit from other materials, to add or change shaders connected t
Inheritance of material-type custom nodes is also allowed, so that new or changed input values can be applied on top of those specified in the inherited material.
+### Named Constants
+
+The MaterialX data library contains many nodes that have inputs with a number of common semantic default values, for instance zero or one. The MaterialX data library also uses a number of different concrete types, for example `float`, `color3` or `vector4`. These types each have different concrete values to represent these semantic defaults. <typedef> elements can be extended with child <constant> elements defining these named values.
+
+Attributes for <constant> elements:
+
+* `name` (string, required): a unique name for this <constant> element
+* `value` (string, required): the concrete value for the given type that should be used during the substitution.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+These named constants can be used anywhere a concrete value is accepted, ie. in any `value` or `default` attribute. The named constant is referenced by prefixing the name of the named value with `"Constant:"`.
+
+```xml
+
+
+```
+
+This example, when combined with the example <typedef> elements above, is functionally identical to:
+
+```xml
+
+
+```
+
+Not every <typedef> is required to define each named constant. Expansion of a named constant will raise an error if a specified name is not defined for the given <typedef>.
+
+### Templated Definition Elements
+
+To reduce potential repetitive data library elements, any number of elements can be enclosed within a <template> element scope. The elements inside the <template> scope are concretely instantiated using the provided template attributes.
+
+Attributes for <template> elements:
+
+* `name` (string, required): a unique name for this <template>
+* `varnames` (string, required): the names of variables to be used for substitution in the contained elements as a comma-separated list.
+* `options` (string, required): the set of concrete values to be used during the substitution of the specified `varnames` in elements contained within the <template>, specified as a string of comma-separated lists of comma-separated strings surrounded by parentheses.
+
+When a <template> is expanded, all the child elements are instantiated exactly once for each entry in the `options` array. These instances replace the original <template> element in the document. They are placed at the same scope level as the original <template> element in the document.
+
+Each instance of the contents contained inside the <template> is processed as it is instantiated. This processing step inspects all attribute values in all the contained elements and replaces any occurrence of any specified string with the corresponding value from the `options` array. The specific string used for the string replacement matching is constructed by wrapping any of the values in the `varnames` list with `@` characters. For example, if `varnames` has the value `"foo"`, then the matching string would be `"@foo@"`. We surround the value of `varnames` with the `@` characters to ensure we do not have any accidental matches.
+
+```xml
+
+
+
+
+
+
+
+```
+
+In this example, the provided `varnames` attribute is `"typeName"`, and so the matching string is `"@typeName@"`. Each instance of this string is then replaced by each element in the `options` string array, `"float"`, `"color3“`, and `"vector4"`.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+When used in combination with the [Named Constants](#named-constants) expansion, this example would become the following concrete set of fully expanded elements.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+When multiple variable names are specified, each of those variables will be substituted simultaneously. This means that the list of options corresponding to each variable is required to be the same length.
+
+```xml
+
+
+
+
+
+
+```
+
+If there is a mismatch in the lengths of the options lists, then an error will be raised during expansion. The example below demonstrates different lengths of options lists; this is invalid syntax.
+
+```xml
+
+
+
+
+
+
+
+```
+
+The `TP_multivariable_example` would be expanded to three concrete instances of the elements it contains, and both `@numberName@` and `@numberValue@` strings would be replaced.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+<template> elements can be nested, and then are expanded sequentially, from the outer scope to the inner scope. This allows <template> element variable substitution to be used to define other template attributes.
+
+```xml
+
+
+
+
+
+
+
+
+
+```
+
+Here we have two nested <template> elements. `TP_ND_add_matrix` will be expanded first. This is important as here the inner <template> element uses the `@typeName@` template variable reference in its definition. This first <template> would be expanded resulting in two instances of the contained elements, since the options list `(matrix33, matrix44)` has length two.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+This results in two "inner" scoped <template> elements, `TP_ND_add_matrix33FA` and `TP_ND_add_matrix44FA`. These then both each get expanded and both result in a further two instances of each set of contained elements, because all the options lists for each of the variables are also of length two, `(matrix33,matrix33FA)` and `(matrix33,float)`.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```