-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Responses can conform to multiple, modular profiles (UC 5.3) #217
Comments
@kcoyle feels that this requirement is not sufficiently traceable to specific Use Cases. On review I felt this was a fair comment, and have proposed a new use case to explicitly state the DCAT-AP concerns at a high level. #238. To resolve we should: 1) refine and accept the UC Possibly the sub-requirements accepted as part of 6.8.2 Profile representation [RPFRP] should be separated out into individual requirements and voted on systematically to verify that consensus is achieved, and concerns about specific aspects can be isolated and discussed on their merits. (Procedurally do we need to revisit this requirement with a proposal to revoke previous consensus acceptance and a new proposal to accept all the reworked sub-requirements for discussion ? Logically this would seem to need to be injected into the workplan for resolution before we could get back to solutions ) |
@rob-metalinkage At the F2F Jaroslav and I took on the action to revisit the use cases that inform profile representation and derive requirements specific to each UC. I have started that in a G-Doc and will try to have something in email to group by start of (the various) day(s) Monday. We should also gather the proposed new Use Cases (there are a few) and decide if we accept them into our work. |
Effectively a duplicate of #212 |
I disagree that this is a duplicate of #212, as far as I understand the two. That one is about the composition of profiles, this one is about the application of profiles to data instances. The implications of this issue is that the relationship between instance (as carried in the http response body) and profile is many to many, not many to one. Thus the design of the HTTP response header that conveys the profiles supported must allow multiple values. |
There's more discussion of this at https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit#heading=h.pgizj2q0xbuh . This is a use case written by Ruben and there has been quite a bit of discussion about what "modular" means. I don't think there's disagreement about multiple values, the question is whether profiles can consist of individual modules that are served during conneg (see the example given in the UC). |
This is a duplicate of #287 and should be removed |
No description provided.
The text was updated successfully, but these errors were encountered: