select results appear as graphs in the 1.0 test suite

[lisp]

for instance, the sort tests provide results as rdf (eg., :dawg-sort-1 uses result-sort-1.rdf) and the solution-seq tests provide results as turtle (eg., :limit-1 uses slice-results-01.ttl ).

the rdf media type is included as https://www.w3.org/TR/rdf-sparql-XMLres/ in the sparql query recommendations, but use of solution indices is not described in its recommendation and its schema defines them as attributes, rather than sibling elements to bindings.
the turtle media type may be analogous to the rdf encoding, but necessarily diverges from the rdf xml schema, as it does not permit attributes.

while to switch to a solution media type introduced by 1.1 could be a backwards compatibility issue, how significant is it at this point to support testing a strictly 1.0 implementation?

[afs]

It's the only way to record order.

[lisp]

yes, if the results are recorded with those media types.

while to switch to a solution media type introduced by 1.1 could be a backwards compatibility issue, how significant is it at this point to support testing a strictly 1.0 implementation?

the question is, at this point, would it not be appropriate to substitute media types which are required by 1.2 and better suites for results which comprise solutions?

[Tpt]

It's the only way to record order.

Is it? The existing SPARQL result formats are inherently ordered. If we add something like a mf:ordered true flag to the test description in the manifest we can state that the results comparison should be done while taking order into account. I guess it would allow to remove the .ttl and .rdf files describing solution-based results.

[afs]

While it is perhaps natural to retain order reading a results format file, I don't believe it is defined as such. A client can look in the query and assume it is ordered for the intended application purpose, but that isn't so simple at the system level because ordering may by partial.

.srx files did at one time have an "ordered" indicator - IIRC it was removed because order may by partial.

It would need a change to the existing test setup. Adding mf:ordered requires changes to existing test runners. A trade-off of "better" and legacy.

The URI for rs: does resolve to a document https://www.w3.org/2001/sw/DataAccess/tests/result-set with rs:index.

[afs]

the question is, at this point, would it not be appropriate to substitute media types which are required by 1.2 and better suites for results which comprise solutions?

That presumes test runners work over HTTP. That is not always the case.

[lisp]

the question is, at this point, would it not be appropriate to substitute media types which are required by 1.2 and better suites for results which comprise solutions?

That presumes test runners work over HTTP. That is not always the case.

how does the media type of the expected solution presume an http request process?
there are already several dozen tests which specify a sparql-results+json result document .

[Tpt]

While it is perhaps natural to retain order reading a results format file, I don't believe it is defined as such.

My bet would be that most processing systems of SPARQL query results retain order: if not, ORDER BY becomes mostly useless outside of its side effects on e.g. OFFSET/LIMIT or non commutative aggregates.

It would need a change to the existing test setup. Adding mf:ordered requires changes to existing test runners. A trade-off of "better" and legacy.

Yes!

[afs]

how does the media type of the expected solution presume an http request process?

Media type applies to protocol, not reading files from local disk.

[lisp]

how does the media type of the expected solution presume an http request process?

Media type applies to protocol, not reading files from local disk.

how does the test harness decide how to read a given file without inferring its media type from the respective file name type extension?