Re: Draft response to ISSUE-105: @itemref support

On Fri, 14 Oct 2011 21:38:21 +0200, Jeni Tennison <jeni@jenitennison.com>  
wrote:

> Hi Manu,
>
> On 15 Sep 2011, at 20:27, Jeni Tennison wrote:
>> On 14 Sep 2011, at 02:54, Manu Sporny wrote:
>> [snippety snip]
>>> So at this point, we need a compelling use case that would outweigh  
>>> the fairly large implementation burden for a feature like @itemref. We  
>>> are also very concerned that allowing multiple subjects in @about  
>>> would be very confusing to authors.
>>>
>>> What are your thoughts on this Jeni? @itemref is helpful in a few  
>>> scenarios, but it seems as if the trade-offs are not worth it to the  
>>> Working Group. Do you have anything else to add? If there is no new  
>>> evidence, the WG will probably close the issue due to the technical  
>>> complexity and the lack of compelling use cases.
>>
>> I understand the trade-offs and appreciate you taking time to look at  
>> this. I'm going to try to find use cases for you, if there are some. I  
>> wonder if you could hold the issue open for a while? If I don't manage  
>> to dig any out, then obviously it's fine to close the issue, but I'd  
>> like to get some input from others rather than make up use cases myself  
>> that may be based on false assumptions.
>
>
> I asked the HTML Data TF whether anyone there had any use cases for  
> shared properties as supported by itemref, or was prepared to go hunting  
> for them, but no one did. Given that, I'm quite happy to drop it.

itemref is not only for shared properties, arguably the more important use  
case is for when the data is not all in a single subtree, e.g. as in  
http://www.2gc.co.uk/a2gc-people

Given that it's useful and implemented in both content (previous link) and  
implementations (Opera), why would we consider dropping it?

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 17 October 2011 09:15:17 UTC