Re: Canonicalizing relative URLs seen in URL type properties?

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 Thursday, 20 October 2011 11:18:48 UTC