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

Re: Canonicalizing relative URLs seen in URL type properties?

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Tue, 25 Oct 2011 18:46:11 +0200
Cc: public-vocabs@w3.org
Message-Id: <81C8D23D-7F05-43F4-B893-C603990295A6@ebusiness-unibw.org>
To: Philip Jägenstedt <philipj@opera.com>
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?

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.


On Oct 20, 2011, at 1:18 PM, Philip Jägenstedt wrote:

> On Thu, 20 Oct 2011 11:43:49 +0200, Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote:
>> Okay, so we are in agreement that both for itemtypes and for href values that identify enumerated entities, the canonical URI must be used without any variations that RFC2616 may allow at the protocol level.
> For itemtypes, yes, but what are "href values that identify enumerated entities"? An example may make things clearer:
> <base href="http://example.com">
> <p itemscope itemtype="httP://fOOlip.Org:80/ex">
>  <a itemprop="p1" href="httP://fOOlip.Org:80/foo">bla</a>
>  <a itemprop="p1" href="bar">bla</a>
> </p>
> The JSON representation of this is:
> {
>  "items":[
>    {
>      "type":"httP://fOOlip.Org:80/ex",
>      "properties":{
>        "p1":[
>          "http://foolip.org/foo",
>          "http://example.com/bar"
>        ]
>      }
>    }
>  ]
> }
> In other words, the item type is not resolved, while the properties are. Resolving is effectively a form of normalization.
> (Note: I haven't updated Live Microdata to handle multiple types yet, so the JSON above is slightly incorrect.)
>> I think that is a good consensus; I seem to have misunderstood your earlier comments about URLs for itemtypes.
> My earlier comments were about URLs as property values, i.e. in itemprop. Perhaps that is where the confusion is?
>> Quite clearly, advanced consumers of Microdata will try to be tolerant and catch common mistakes / variations, but that is outside the specification level.
> I have to disagree strongly with this. A consumer that does anything beyond what the spec requires is non-conforming. If there are any common mistakes that need to be handled, then the spec should be changed so that all conforming implementation do the same thing.
> -- 
> Philip Jägenstedt
> Core Developer
> Opera Software
Received on Tuesday, 25 October 2011 16:46:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:48:43 UTC