The general (Gear 6 and EDI Samples) approach would be:
Create an N1 segment mapping service (named somthing like "mapN1Segments) that has a list of N1 documents as the service input. The service output would contain a separate document (or a signle document with multiple child document types) for every type of N1 segment you expect. The output documents represent XML fragments for just the <address> (N1 equivalent) elements you are creating.
Within the service, loop over the N1 list, and inside the loop, branch on N103 to populate the different output documents.
I have found that as requirements change over time (new N103 types come into play), it is inconvenient to change segment mapping service output specifications. So all of my segment mapping services take both EDIValues and a canonical as both input and output.
This allows the segment mapping services to hide the details of how they build the canonical, and be invoked as a sort of “assembly line” that builds-up the canonical a bit at a time. New segment mapping services can be inserted in the outer flow in any order, and no fragments need to be managed in the outer flow.
Since now the segment mapping service has knowledge of the canonical, the price of this approach is that you need different N1 (for example) mapping services for each transaction set type you handle. I have found this to be a price worth paying for the simplification it offers in the outer service.
Regards
-Mark