<port Y>
<relation type="inNode">
<node id=A />
</relation>
</port>
<node id=A>
# some added properties from X's perspective about A
# some added properties from Y's perspective about A
</node>
Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A.
Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous.
I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity.
Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined
Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere.
We'd make use of anonymous network elements inside of relationships:
<relation type="hasPort">
<port>
<relation type="definedBy">
<port id="XYZ" />
</relation>
</port>
</relation>
The above syntax was shortened using the idRef to:
<relation type="hasPort">
<port idRef="XYZ" />
</relation>
To me, these semantics are logical, and allow scoping properties about a network element.
Cheers,
Aaron