Support reusing the same Element class under different Segment context.

[cleftheris]

The issue here is that although Element to Class binding is supported there is currently no way to make declared paths relative. Thus the element to POCO class feature is almost useless.

For example if an element (group of components) for the address field occurs more than one in a Message type there could be one class to handle the deserialization. Now the class is bound to one and only segment occurrence because Paths are treated as absolute and are not combined & computed on deserialization

[cleftheris]

Copied over from #14

This issue is related to cases when an Element (a set of components) is resurfacing under different segment name. Lets say we got the AddressInfo complex type and it is on the second element of segment XXX\1 and the third element of YYY\2. Currently there is no way to reuse class AddressInfo one must make two copies or subclasses of that for each location. The above problem I have found is more related to how a TRADACOMS transmission is layered out.

On EdiFact on the other hand, Segments are used as the main org unit. So in this case the flexibility to reuse a class is fully supported. Check for example this model and how the DTM segment is handled.

[cleftheris]

@thizzo Following the discussion on #104, I find your proposal interesting and I am aiming for something similar but without introducing a new Path attribute for Elements since I want to keep complexity to a minimal set of attributes.

What I am proposing would have some kind of known wildcard character to declare dynamic path like the following.

[EdiElement]
public class CompositeDataElement 
{
    [EdiValue("X(18)"), Path="?/?/0"]
    public string A{ get; set; }    

    [EdiValue("X(3)"), Path="?/?/1"]
    public string B { get; set; }    

    [EdiValue("X(70)"), Path="?/?/2"]
    public string C { get; set; }
}

[EdiSegment, EdiPath("BBB")]
public class SegmentB
{ 
    [EdiPath("BBB/1")]
    public CompositeDataElement { get; set;}
}