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? 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 > > > > >>> >>> >>> >> >> >> >> >
