Dave suggests implementation details are important. As one of those who made the “implementation detail” claim, I’ll state my definition;
An “implementation detail” is an aspect of the design or implementation of a system, which has no effect on the architecture of that system, i.e. does not affect the relationships between components, connectors, and data.
Dave had argued for the use of EPRs instead of URIs based on what I believed to be “implementation details”, including this;
Separating the reference property from the URI may make it easier for service components to evolve. A service component may know nothing about the deployment address of the service from the reference properties. This effectively separates the concerns of identifiers into externally visible and evolvable from the internally visible and evolvable. For example, a dispatcher could evolve the format it uses for reference properties without concern of the URI related software.
to which I responded;
That separation you discuss is an implementation detail, not an aspect of the architecture. Consider Web servers that have a config file which is used to map URIs to code, freeing up the code from having to be bound to any particular URI.
Which is to say that the config file used by the Web server is not a part of the architecture of the operational system being discussed, because it is not exposed to the service consumer (not a data element), nor does it impact connector (transfer) semantics or the relationship between components. It would be a data element of the configuration subsystem architecture of course, but that’s not what we’re talking about.