You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 26, 2020. It is now read-only.
The LinkModel::Rates XML-Element defines the required attribute "m" to specify the Application Model which is subject of this Rate.
Problem:
Since we support alternative data formats and partial models, the ID-Reference just to an Application Model is ambiguous: the underlying Data Ressource in question cannot be determined uniquely without further context or semantic restrictions.
Possible Solutions:
Use the same mechanism as the Relatum XML-Element: introduce two new optional attributes "f" and "r" having the same semantics as in Relatum. Pull "m", "f" and "r" up to a common XSD-Attribute Group.
Look for the Data Ressource by searching for the given Application Model-ID and corresponding "f" and "r" Attributes in all Relata of the containing Link. This requires that just a singular Data Ressource of each Linked Application Model may be used in one Link. Although this is implicitly implied by specifying the Linked Models of an LinkModel only by their Application-ID, the requirement must be stated explicitly by the XSD-Documentation of Link and Relatum. Choosing this solution would break the semantic backwards compatibility of this Schema: there might still exist Multimodel-Containers which do not meet this new requirement.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The LinkModel::Rates XML-Element defines the required attribute "m" to specify the Application Model which is subject of this Rate.
Problem:
Since we support alternative data formats and partial models, the ID-Reference just to an Application Model is ambiguous: the underlying Data Ressource in question cannot be determined uniquely without further context or semantic restrictions.
Possible Solutions:
The text was updated successfully, but these errors were encountered: