Re: Some RDFa 1.1 Core edge cases that we need to clarify

Ivan Herman wrote:
> On Oct 25, 2010, at 17:45 , Toby Inkster wrote:
> 
>> On Mon, 25 Oct 2010 13:15:44 +0100
>> Martin McEvoy <martin@weborganics.co.uk> wrote:
>>
>>> The second vocab attribute "2#" would resolve to
>>> http://example.com/base2#which may be wrong?
>> No, that's not how base works. Check this in a browser:
>>
>> <html>
>> <base href="http://example.com/base">
>> <a href="2#">hover over this link, look at status bar</a>
>> </html>
>>
>>> I think @vocab should always be an absolute URI (easier to parse an
>>> less complicated) 
>> We already need to support relative links in @about, @resource, @src
>> and @href, so supporting relative URIs in @vocab is not too much to ask
>> from a parser.
>>
>> Actually, re-reading the RDFa Core 1.1 spec, it seems we already allow
>> @vocab to be relative (or at least we don't seem to forbid it
>> anywhere). If so, then it seems my concerns are unwarranted, and
>> vocab="2#" is well-defined.
> 
> That was my reading of the document, too. It is a URI, that can be relative. I do not think we have a problem here.

Likewise, I see no problem - every URI/IRI(-Reference) can (should) be 
passed through a function which resolves it against the base prior to use.

The algorithm [1] is well defined in RFC 3986 [URI], pointed to for 
usage by RFC 3987 [IRI], handles everything from absolute through to 
fragments, and is implemented in almost every environment where you find 
a URI.

Thus all things considered, I don't see why one attribute (@vocab) 
should be treated specially when best/current practise is to resolve all 
URIs that appear anywhere in a document prior to usage.

[1] http://tools.ietf.org/html/rfc3986#section-5.2.2

Best,

Nathan

Received on Tuesday, 26 October 2010 15:22:24 UTC