Skip to content
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

qualify service5 with a feature for variable service locations #12

Open
lisp opened this issue Oct 15, 2015 · 3 comments
Open

qualify service5 with a feature for variable service locations #12

lisp opened this issue Oct 15, 2015 · 3 comments
Labels

Comments

@lisp
Copy link

lisp commented Oct 15, 2015

as the semantics for variable service locations is not well defined, it is not appropriate to require its unqualified implementation in order to demonstrate performance.
either add a distinct feature for their support or define an alternative to sd:BasicFederatedQuery to indicate the extended implementation.

@afs
Copy link
Contributor

afs commented Oct 17, 2015

The tests should be labelled in the manifest); IIRC that was going to be done but seems to have not happened. The "labelling the manifest" approach is used elsewhere in the tests. A separate issue is whether endpoints that have a query processor that has this feature. Modifications to the service description vocabulary are out side testing. Maybe send a comment to the comments list for any future WG to consider.

@lisp
Copy link
Author

lisp commented Oct 17, 2015

there is a label in the manifest, but it is the same as for a test with a constant location.
if we need to extend the service description in order to adequately describe tests, do we have to start our own vocabulary?

this question is relevant beyond the federation tests, as there are other aspects, where the features are not sufficient to distinguish among variations in what should be conformant behavior.

@gkellogg
Copy link
Member

It may be that forward-compatible updates the the test vocabularies are in-bounds, it needs checking with the powers-that-be. @ericprud, can you comment?

Of course, another alternative would be to simply define required vocabulary terms directly in the test manifest itself.

@gkellogg gkellogg added the SPARQL label Nov 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants