W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2011

Re: Canonicalizing relative URLs seen in URL type properties?

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 26 Oct 2011 10:16:18 +0200
To: "Martin Hepp" <martin.hepp@ebusiness-unibw.org>
Cc: public-vocabs@w3.org
Message-ID: <op.v3x89gm2sr6mfa@kirk>
On Tue, 25 Oct 2011 18:46:11 +0200, Martin Hepp  
<martin.hepp@ebusiness-unibw.org> wrote:

> Hi Philip,
>
> I am still unconvinced that normalizing property values is a good thing,  
> because it would mean
>
> a) you have to execute an http GET for handling every single property  
> value or
> b) implement the normalization rules for any of the URI schemes out  
> there (e.g. FTP, mailto, ...) - and what about non-registered public  
> schemes?

You need to implement the "resolve a URL" algorithm [1] which takes care  
of all of this and does not have any scheme-specific rules AFAICT.

> IMO, it would be better to treat URIs as identifiers simply as strings,  
> with maybe minimal character encoding normalization.
>
> Also, I must say that the different handling of URI normalization  
> depending on whether used for itemtype, itemprop, or href/item value  
> reminds me of the worst features of RDFa in terms of complexity.

The only values that are resolved are the property values in the href/src  
attributes on a, area, audio, embed, iframe, img, link, object, source,  
track, and video elements. Not doing this would make microdata useless for  
marking up relative URLs, while trying to be "consistent" and resolving  
all URLs would also mean resolving the itemprop tokens (which can be  
absolute URLs), which just doesn't make any sense in the microdata model.

In any event, feel free to file spec bugs for things that are confusing or  
that you want changed. That's what I do and sometimes I get my way.

[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolve-a-url

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 26 October 2011 08:16:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:56 GMT