There are two approaches we could try to solve this problem. One is to identify the ingress and egress STP for each domain in the path, and the other is to specify the ingress and egress STP that makes up and SDP.

This was what I was thinking of on the call for a modification to the existing structure to address the first approach. Ingress means it enters a domain associated with the STP, and egress means it leaves the domain associated with the STP. This gives us directionality of the path.

<xsd:complexType name="OrderedServiceTerminationPointType">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A Service Termination Point (STP) which can be ordered in a list for
use in PathObject definition.

Attributes:

order - Order attribute is provided only when the STP is part of an
orderedStpList.

Elements:

ingressStpId - the unique identifier for the STP identifying the ingress point of a network.
egressStpId - the unique identifier for the STP identifying the engress point of a network.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="ingressStpId" type="tns:StpIdType" minOccurs="0" />
<xsd:element name="egressStpId" type="tns:StpIdType" minOccurs="0" />
</xsd:sequence>
<xsd:attribute name="order" type="xsd:int" />
</xsd:complexType>

If you look at the attached diagram we are using in the other discussion, I can model the outlined path as follows (order, IngressSTP, egressSTP):

(1, A.User, A.B), (2, B.A, B.D), (3, D.B, D.E), (4, E.D, E.User);

We could even model the User A end of the connection by leaving out the ingressSTP and only providing the egressSTP:
(1, null, User.A), (2, A.User, A.B), (3, B.A, B.D), (4, D.B, D.E), (5, E.D, E.User);

Interestingly enough, if we specify the links instead of the entry and exit points of the domain, we can use the same structure but we get:

(1, User.A, A.User), (2, A.B, B.A), (3, B.C, C.B), (4, D.E, E.D), (5, E.User, null);

Was this close to what you were thinking?