hibaymj
commented
7 years ago This issue might be old, but as it is still open and has not been addressed within the specification I will add my thoughts.
I believe the profile should be applied not just document wide, but application wide. Through using full IRI rel names, the UBER format can provide the developer the ability to change their own format, while trying to change a profile might be out of their control. Additionally, if applying a large profile to a subsection, implementing reactive consumers of the service could be overly burdensome, and only conditionally apparent to the client designer. Finally, I would argue that if a collision is happening from a referenced profile the designer has chosen to describe their service, an attempt to rename or override the inherited semantics, they are fundamentally breaking the contract they have chosen to abide which should be discouraged.
I also had some additional questions so I'll just pile onto this issue to add them as well.
When using ALPS and UBER, there seems to be a conflicting demand for the highest precedence when determining which document is the source of truth the server will adhere to when sending a response over the wire. As neither specification supports the concept of currying, namespace issues could surface unless using full IRIs as the rel name.
It makes sense when defining a specification to establish the order in which the service will guarantee it's aggregate vocabulary. As ALPS is capable of defining vocabularies of varying size, from a micro-vocabulary to an entire domain model with cross media type functionality I suggest the specification prioritizes the profiles in order of appearance over the UBER defined vocabulary.
This would provide adherence to the profiles global contracts, and afford the API developer the most control over how the client should interpret its response.
This suggestion does however bring up an issue which a solution does not immediately come to mind, where multiple profiles have conflicting desirable definitions and it is impossible to order them in the desired fashion.
what happens when two profiles create conflicting definitions? is a profile's scope ALWAYS doc-wide or can you apply them (like NS) to sub sections of docs? at runtime, how does the client work out details of all this?