On 16/09/14 08:47, Rob Vesse wrote:
Yes looks like email managed it a bit but you got the correct gist, a IRI
with http:/ I.e. only a single slash followed by some further path
components
If as you say this is a valid albeit unusual IRIe how come the IRI
validator rejects it? Is it requiring that all IRIs be absolute?
The IRI code has a bunch of things it detects. The IRI factory is then
set to decide what to treat as fatal errors and which to report as
warnings but continue.
The IRI validator prints out all errors and all warning IRI code
reports. It's set more verbose than other code.
------
Where are you parsing these queries? App code? Fuseki?
It might make sense to have relative URIs in some more circumstance
default to at least logged warnings, and maybe as error.
(actually: http:/foo is an absolute URI! All "absolute" means is does it
have a scheme name. As an http URI isn't incomplete (I'm not sure if
there is a technical term for a "complete" HTTP URI with authority and
path is)
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
and the example is case 2 : path-absolute, not case 1.
Andy
Rob
On 15/09/2014 19:25, "Andy Seaborne" <[email protected]> wrote:
On 15/09/14 11:25, Rob Vesse wrote:
Found one way of doing this:
query.setBaseURI(new IRIResolver());
However you have to do this in the setup of the parser before the query
is
parsed which is not something your average user will have access to and
setting it after parsing has happened has no effect.
So how would an average user who is not customising the query parser
enable strict IRI parsing?
Rob
On 15/09/2014 10:31, "Rob Vesse" <[email protected]> wrote:
Is there an easy way to enable strict IRI parsing in the query parser?
For example the following user query is accepted by ARQ:
SELECT *
WHERE {
?subject rdfs:subClassOf <http:/google.com <http://google.com/
<http://google.com/>>> .
}
(not sure if email has damaged that example)
Note the incorrect URI, when put through the IRI validator at
sparql.org
ARQ produces the following:
http:/google.com ==> http:/google.com
<http:/google.com> Code: 57/REQUIRED_COMPONENT_MISSING in HOST: A
component that is required by the scheme is missing.
Is there any way to get this behaviour from the query parser?
Rob
http:/path is a valid URI - it's a rather odd one but the host name is
optional and when resolved will be the host name of the base.
It does occur for real on the web - e.g. https:/login swaps the protocol
to https if you were using http: and it works whatever hostname you got
to that page from.
Andy
