- From: aisaac via GitHub <sysbot+gh@w3.org>
- Date: Tue, 03 Jul 2018 22:16:24 +0000
- To: public-dxwg-wg@w3.org
I'm quite split. To me in theory the use case could be approved, requirement(s) derived from it, and then we decide to reject the requirements if we think they're too much at odds with web architecture. This is tedious, but this would document why we've not gone this way. And I think this can be useful, as others may claim that this use case corresponds to a desire they have. For one I would understand that people used to the OAI-PMH parameter could be tempted to push for this have this pattern still available in a more general setting. So with this in mind I would vote for saying that the use case is in scope. On the other hand, our charter (https://www.w3.org/2017/dxwg/charter) dictates that content negotiation by application profile should be the only delivery option that we explore. So this would be a reason to rule out the part about using alternatives to negotiation. The one thing the charter does not explicitly reject would be the part about discovering the available profiles, i.e. the `ListMetadataFormats` parameter from OAI-PMH (https://www.openarchives.org/OAI/openarchivesprotocol.html#ListMetadataFormats). But without the other pattern to access data in certain profiles without conneg, this would be a bit moot. In any case, @nicholascar has answered the questions I had. And the title could be indeed changed to reflect better the content of the use case. I had understood 'profile information' to be 'metadata describing the profile', i.e. ProfileDesc statements... @larsgsvensson @RubenVerborgh @rob-metalinkage I have an action to call for your feedback about this case, now that it's been edited by Nick :-) -- GitHub Notification of comment by aisaac Please view or discuss this issue at https://github.com/w3c/dxwg/issues/239#issuecomment-402307871 using your GitHub account
Received on Tuesday, 3 July 2018 22:16:31 UTC