Further updates.

site/dev/design-notes/Proposed-DFDL-Standard-Profile.md

@@ -72,9 +72,51 @@ This enables one to create unique identifiers by concatenating prefix_local to c
 
 All children element declarations must have unique names within their enclosing parent element.
 
+#### Discussion
+Note that this causes issues in a number of large DFDL schemas (e.g, VMF) which attempt to implement a 
+single DFDL schema that is capable of handling multiple versions of the data format.
+
+In this case, the schema uses a construct like:
+```xml
+<choice>
+  <sequence>
+    <element name="C" type="zString"/>
+    <element name="hdr" type="hdr_version_C_type"/>
+  </sequence>
+  <sequence>
+    <element name="D" type="zString"/>
+    <element name="hdr" type="hdr_version_D_type"/>
+  </sequence>
+</choice>
+```
+In the above, you can see that there are two separate element declarations named hdr, of different types. 
+This allows common sub-structure that is the same in versions C and D to be addressed by path expressions that are
+polymorphic. They do not have a path step component that identifies the version. 
+
+However, if we require all children to have unique names, then this would have to be elements with distinct names on each
+branch such as hdrC and hdrD, and then paths, even those reaching sub-fields that are common to both versions, 
+have path steps that are specifically requesting a particular version. 
+
+This is a bit painful particularly if there are many expressions that need to reference into the common fields, because
+all such expressions would need to be duplicated for version C and version D. 
+
+An alternative solution is that this could be overcome by a way of creating path expressions with wildcards in 
+them eg., ".../hdr*/...".
+An extension of this kind in DFDL has already been proposed/discussed some time ago by the DFDL workgroup, but has 
+not yet turned into a formal proposal. (The DFDL4Space implementation by the ESA has a kind of wildcard feature like
+this as a DFDL extension.)
+
+Another way of addressing this is to put the version distinction at precisely each point of difference between the 
+schema versions. 
+This is, however, not the way some large schemas were created, as these schemas are machine generated from the 
+individual format specifications. The generator is not aware of the individual differences between the versions,
+but only that there are *some* differences between them. 
+It requires a more sophisticated schema generator to compute these fine-level diffs between the two schemas. 
+
+
 ### Nillable Simple Types Only (TBD: May not be necessary)
 
-Nillable is allowed only for simple type elements.
+Nillable is allowed only for simple type elements. 
 
 ### Element Name/Identifier Restrictions