Add choice to have embbed DistanceMatrixElement in ParameterAssignmentScopeGroup

[syversenkr]

Necessary when constructing Norwegian sales offers (GenericParameterAssignment) data streams, and subsequently also for purchase package (CustomerPurchaseParameterAssignment) streams, which will include "dynamic" (on-the-fly generated) DistanceMatrixElement objects

[Aurige]

There is also the DistanceMatrixElementView and may be DistanceMatrixElementInverseRef
We also need to explai why this one can be embedded where others assignments are refs

[syversenkr]

@Aurige
We looked into the option of rather using DistanceMatrixElementView, but there are some issues in using a DerivedView in this scenario:

• It is not referable in a normal ID+version manner (version attribute missing) after being added (must be treated as special cases in the implementation)
• This particular view (currently) is missing some data elements from DistanceMatrixElement which may be relevant to add (e.g. Distance, validity, possibly FareTableRef)
• Using a View implicitly presumes that there is, or at least could/should be, an actual element corresponding to the DerviedView. (I.e. from which the view is derived.) However, should there be a case of multiple DistanceMatrixElement with the same Start and Stop StopPoint and/or TariffZone, there is currently no way to derive from the view which is the corresponding object.

Regarding the latter point, using a view brings us most of the same issues (and some additional issues) as having a separate, pre-created set of DistanceMatrixElements and refering them in a regular manner. That is the reason for requsting this addition, enabling on-the-fly creation of full DistanceMatrixElement with ID, version and is full data set, to enable refering back to it (after being created as part of the assignment) later downstream.

But we did notice that assignment objects where harmonized as references throughout. And if this addition is deemed unsuitable in the model, we will have to investigate further technical solutions. Either generationg/maintaing this data outside of the sales offer / purchase package scope, if possible, or see if we are able to work around this problem using other structures or mechnisms. If so, I will close this pull request later.

As for the DistanceMatrixElementInverseRef ("Reference to a DISTANCE MATRIX ELEMENT, used in a backwards direction"), this reference did not seem relevant in our case: From its documentation I interpret this to be a reference to usage of a DistanceMatrixElement (presumably with InverseAllowed = "true", or not set, to be allowed at all? ; this was not clear cut in from the documentation), not a construction or alteration thereof.

[Aurige]

@syversenkr sorry, I was not clear, I was not meaning using the view for your use case (also it was interesting to check and know why it does not fit) but since you introduce a new choice, that may make sense to have all the DistanceMatrixElement related possibilities under it (I don't think there is any interest in feeling several of them, and that's a risk of unconsistency).
Thanks for the detailed answer anyway

[syversenkr]

And @seime, kudos to him the very keen observer, just pointed out to me in a different channel: From Transmodel v6, "A view may have a persistent identity and version, but all its attributes are derived..." Which means that the abstract DerivedViewStructure in NeTEx should have a "version" attribute added.

[nick-knowles]

you are right when you say " But we did notice that assignment objects where harmonized as references throughou". The design pattern is that an assignment links existing entities, it does not define entities in its own right. Doing so smells like an ugly hack . I really dont think we should be embedding declarations of elements in an assignment.
Would a GroupOfDistanceMatricElementsRef do the trick - you could dynamically change the contents of the group? Otherwise I would consider something like adding a special dymanicACcessRights assignment

[syversenkr]

@nick-knowles / @Aurige
We see that references is normatime for the validityParameters list. However this is not the case for the list of limitations, where most (all?) can be either a reference or an embedded object.

For this reason, it did not feel like that much of a hack or cluttering of the dataset, from the viewpoint of the the NeTEx XML.

GroupOfDistanceMatrixElementsRef does not help for our use-case, unfortunately, as this still means the DistanceMatrixElement(s) must be maintained/spooled in parallel to rather than part of the ParameterAssignment.

[nick-knowles]

This still feels somewhat wrong in that it is redundant . The idea is that you use a TARIFF to (i) declare all the tarifff elements (GEOGRAPHICAL INTERVALS, TIME INTERVALS, DISTANCE MATRIX ELEMENTS, QUALITY FASTRUCTURE FACTORS, etc etc) and then (ii) use FARE STRUCTURE ELEMENTs to specify how they are used .

The limitation elements are a distinct case - they are all UsageParameters - A parameter assignment is usually the place they are defined for use as part of a FARE STRUCTURE ELEMENT and they are usually specifc to that assignment. The DIstance matric elements are in principel resuable.

Why not just use a TARIFF element to group your "dynamic distance matrix element" (whatever that is) with the FARE STRUCTURE ELEMENT containing the VALIDTY PARAMETER ASSIGNMENT that references it.?

It would be fine to and a version to an View if you need it thoiugh.

[syversenkr]

Replaced by PR #151 (@seime) per workshop with @nick-knowles