I have analyzed this use of (.*) notation in the Sentinel2X-bandTMISPData.xsd file.
Below is my discussion of what this is, why it is used, the alternative to it, and why it is more problematic than it seems at first, as an addition to DFDL.
There are two instances of (.*) in the Sentinel schema files.
What it expresses is a partial step-name wildcard. This is not a variation on the XPath * notation, as that matches any step, and can't match a partial name. In the usage in the Sentinel schema, this wild card is a regex that matches against a step name, and it matches exactly a single name. It is not used in a way where it can result in a node-set instead of a single node.
The question really is why is this (.*) needed - that is what is it trying to achieve, and whether there is an acceptable alternative for what it is doing.
I find that this wildcard (.*) is used to achieve a parameterization of the types TypeISPData and TypeISPData_HKTM. These types are polymorphic, in that their exact behavior depends on aspects of their surrounding context. Each of these types incorporates a length of some content that is outside of its own definition.
As the types are used now, the length comes from a thing outside of them in the schema that happens to have a particular suffix on its name, which is "Packet_Secondary_Header" or just "_Secondary_Header".
So these names, while outside of the type, are in some sense being hard-coded in these types. Even though they are outside of these types, you cannot change the names of these elements without breaking the ability of the type to find them via this (.*) notation and a name suffix.
These types, TypeISPData and TypeISPData_HKTM are placed inside other types, and those are then placed in context with various packet-header structures. Those structures have various distinguishing prefixes of sub-elemetnts such as MSI_Packet_Secondary_Header. There are a variety of different things instead of "MSI_", but there's always something with suffix "Packet_Secondary_Header" or "Secondary_Header" in it.
The use of this (.*) name wildcard seems convenient, but doesn't offer anything that isn't better captured by a true parameterization mechanism which decouples the names used outside the type from those used inside it.
DFDL provides a general mechanism for this sort of parameterization using variables and dfdl:newVariableInstance.
Let's look at just one of the two instances, TypeISPData.
To use variables, a variable is created which represents this parameter to the TypeISPData. It is declared in the schema file where TypeISPData is defined.
<dfdl:defineVariable name="Additional_
Content_Length" type="xs:int"/>
The expression within TypeISPData that currently contains
"contentLength(/Packet_Data_Field/(.*)Packet_Secondary_Header, 'bytes')"
That part of the expression instead references the parameter variable
$Additional_Content_Length
At the point of use, where this packet secondary header element is combined with the element that contains the TypeISPData, at that location, a dfdl:newVariableInstance is created and bound like so:
...
<xs:element name="MSI_Packet_Secondary_Header" type="TypePacketData_MSI"/>
<xs:sequence>
<xs:annotation><xs:appinfo source="http://www.ogf.org/dfdl">
<dfdl:newVariableInstance
ref="Additional_Content_Length"
value="{ dfdl:contentLength(../MSI_Packet_Secondary_Header, 'bytes') }"/>
</xs:appinfo></xs:annotation>
<xs:element name="MSI_User_Data_Field" type="TypeUserData"/>
</xs:sequence>
...
This binds the parameter to the needed length around the point of use of the type that needs it (which is down inside the TypeUserData)
This seems bulky due to the XML and XSD-annotation notational overheads, but it is just parameter-binding as would occur in an ordinary programming language when passing an argument.
Using variables decouples the names of the two parts of the schema entirely. For example, if MSI_Packet_Secondary_Header were to be renamed to MSI_PSH, it would change only the point of use where the variable binding occurs, and would not affect the type definition. This also facilitates testing the types in isolation. It eliiminates the need to have the complete data structure surrounding them.
Use of (*.) name matching might seem convenient, but really it depends on an unstated invariant about the way names are chosen in the Sentinel schema. If the names weren't constructed so uniformly, this notational trick would be unable to make the necessary distinctions, and you'd have to fall back on using variables.
So, the above explains an alternative, already in DFDL, that can achieve the parameterization of types that is needed.
There is an additional issue that makes this (.*) notation problematic.
The issue is thes semantics relative to QNames and ordinary XML namespace management for name conflict control, The Sentinel schema is all a "no namespace" schema. In that world a path step is just an identifier with no structure. However, more generally in DFDL, a path step might be a QName, and those have a namespace prefix part, and a name part. Name collisions and conflicts can be managed by use of different target namespaces and namespace prefixes. Using (.*) prefix regex-matching against QNames is problematic, as it subverts the ability to use namespace prefixes to eliminate name conflicts. E.g., does (.*)_Secondary_Header match "foo:My_Secondary_Header" given that it is in the foo namespace? Matching against things without taking namespace prefixes into consideration breaks XSD's ability to use prefixes to manage name collsions. So the answer of does "(.*)_Secondary_Header" match "foo:My_Secondary_Header" would have to be that it does not match, and that if one wanted to match that one would have to write "bar:(.*)_Secondary_Header" where bar prefix is bound to the same namespace as foo in the schema file where My_Secondary_Header is defined. This mixture of some plain-textual regex matching, and some name-prefix-qualified namespace-sensitive matching is not very attractive. There is certainly nothing like this in XPath.
Last issue is implementation complexity:
So, if one wants to do without the (.*) notation, in terms of making DFDL4S more complex to implement, you would need to add variables. Fortunately variables are really one of the simpler things in DFDL to implement at least for parsing, and is very simple if the dfdl:setVariable annotation is not implemented since it is not needed in this case.
Each variable has a stack. the dfdl:newVariableInstance pushes a new entry onto the stack, and in this case, populates it immediately with a value.
Reference to the variable from an expression always takes the value of the top-of-stack location.
Exiting the scope of the annotation where the dfdl:newVariableInstance appeared pops the stack.
In summary, given (a) the availability of a robust parameterization mechanism using parameter variables and newVariableInstance to bind them (b) the ease of implementing variables, and (c) the complexity of working out interactions with XML/XSD namespaces/prefixes and name management,..... given those reasons, I would be disinclined to advocate something like this (.*) notation to DFDL unless it was first added to XPath, where all necessary details were worked out for us.