Absolute URIs for Turtle tests

* Gregory Williams <greg@evilfunhouse.com> [2013-07-04 11:05+0300]
> On Jul 3, 2013, at 6:31 PM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * Gregory Williams <greg@evilfunhouse.com> [2013-02-28 10:34-0500]
> >> Gregg Kellogg wrote:
> >> 
> >>> Also the README at <https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/tests-ttl/README> references <http://www.w3.org/2011/rdf-wg/wiki/Turtle_Test_Suite>, which says that tests should all be run with an assumed base of <http://example/base/>. This could probably be more prominent, perhaps in a dc:comment within the Manifest.
> >> 
> >> I'm joining this conversation (and work towards implementing the new turtle) rather late, but I had similar problems to David. Base URI resolution has often thrown me in the past, but I had problems passing some turtle tests based just on what the docs say.
> >> 
> >> I found the claim that "the assumed base URI for the tests is <http://example/base/> if needed" to be very confusing, as I understand it to *always* be needed, but that the resolution rules require that the base URI used when parsing is based on both this URI (which these docs call the "assumed base URI," but which RFC 3986 calls "default base URI") and also the "URI used to retrieve the entity" (in this case the relative URI of the turtle document being parsed). If that's correct, I think the language used to introduce this default base URI should be improved to use language that aligns with RFC 3986 and to remove the phrase "if needed".
> > 
> > The tests have been moved to <http://www.w3.org/2013/TurtleTests/> and
> > the relative IRI resolution is against that location.  The README and
> > <http://www.w3.org/2011/rdf-wg/wiki/Turtle_Test_Suite#Relative_IRI_Resolution>
> > explain this as
> > [[
> > The home of the test suite is
> > <http://www.w3.org/2013/TurtleTests/>. Per RFC 3986 section 5.1.3, the
> > base IRI for parsing each file is the retrieval IRI for that file. For
> > example, the tests turtle-subm-01 and turtle-subm-27 require relative
> > IRI resolution against a base of
> > <http://www.w3.org/2013/TurtleTests/turtle-subm-01.ttl> and
> > <http://www.w3.org/2013/TurtleTests/turtle-subm-27.ttl> respectively.
> > ]]
> > 
> > If this resolution addresses your issues, please respond to this
> > message with a subject line which starts with "[RESOLVED]". Thank you
> > for your help in improving the Turtle specification.
> 
> I consider this issue resolved, but have a further suggestion for the test suite. Would it be possible to have the Turtle test suite manifest use fully qualified URIs for the test identifiers? Currently, all URIs in the manifest are relative, which means that a locally downloaded copy of the test suite does not contain enough data to produce an EARL report with correct test URIs, as the test URIs can end up being resolved against a local file: base.

Apologies, I never looked past the subject to see that this raised another issue.

At this point, the WG has finalized the test suite with the relative links to the input and reference files in the manifest. This format is compatible with the format used in the SPARQL 1.0 and SPARQL 1.1 test suites. An advantage they offer over manifests with absolute URIs is that the parser can execute the manifest either remotely against <http://www.w3.org/2013/TurtleTests/manifest.ttl> or locally against <file://manifest.ttl> without some additional mechanism intercepting GETs against <http://www.w3.org/2013/TurtleTests/foo.ttl> and interpreting them as <file://foo.ttl>. The cost is that the EARL report must be modified in the end, but that can be done with sed.

If this address your comments, please reply with the subject prefixed with "[RESOLVED]".


> thanks,
> .greg
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Sunday, 3 November 2013 16:43:10 UTC