Re: Supported image types

I see your points Rotan and agree, in general.

I guess the next step is to make a list of what the group thinks is  
the core list of sub-types. Maybe a Top N thing like the top device  
properties? It comes immediately to my mind animated GIF, that's a  
very specific sub-type that is actually very common and can also be  
tested easily, at least in its simplest incarnation.

We could each pick 2 sub-types and make a list... Just a suggestion  
off the top of my head that you might discuss during the F2F this week.

- Andrea


Il giorno 14/lug/07, alle ore 22:31, Rotan Hanrahan ha scritto:

> It's the old 80/20 rule again. Some of the sub-type information may  
> be considered highly useful to the vast majority of expected users  
> of a DDR instance, and in that way we can say that such information  
> is core. Thus I agree that DDWG will have to consider how to  
> represent sub-type information. That's something we will do with  
> our UWA colleagues, because the issue is not confined to DDWG use  
> cases.
>
> But much of the detailed sub-type information will only provide a  
> marginal benefit to a small subset of users, and such information  
> may be hard to obtain in general (unless you're willing to spend a  
> small fortune on testing). This kind of information I'd see as  
> being specialised, rather than core.
>
> I'm thinking in terms of guidance items 1 and 4 from the submission  
> form:
> - The property must be considered essential to achieve adaptation  
> of Web content for mobile devices
> - There should be a reasonable expectation of acquiring values for  
> the property
>
> Where we draw the line on sub-types should be influenced by this  
> guidance. Our own experience says that that only a small amount of  
> image data is needed for the vast majority of image adaptation. If  
> you want to go into the space of "approaching perfection", then you  
> need to expend a lot of time and effort to discover the remaining  
> obscure information, and couple that with some fairly advanced  
> adaptation processes. Basically, that's moving into the realm of  
> commercial solutions, and for the DDWG's DDR Core I'd rather steer  
> clear of this realm.
>
> A well-populated instance of the DDR, using just the DDR core  
> vocabulary, should provide the necessary and sufficient information  
> to a reasonably competent adaptation system to produce a  
> "functional user experience" in a mobile context. For me, that's  
> how I want to measure if something is core. Well-populated: because  
> the type of data has a reasonable expectation of being provided,  
> and Functional User Experience: because this DIWG term applied to a  
> mobile context is a sufficient definition of what it means for  
> content/service to be accessible from mobile devices.
>
> The BPWG also gives guidance on the minimum expectations for a  
> mobile Web experience. It would make sense for the core to support  
> such an experience being achieved. (Topic for debate: Would the DD  
> core be sufficient?)
>
> Making mobile content and services very compelling to view and use  
> is a commercial proposition, and I hope that the DDR core will  
> provide a common subset for all such solutions. Over time, what  
> people consider to be a functional user experience will be refined,  
> and maybe the data on devices will become more available. In time,  
> therefore, our idea of core will change. Right now, I'd be happy  
> enough to define a core that makes sense for, say, 2008 (around the  
> time that our group is scheduled to complete its work).
>
> We have a group meeting next week. Let's hope we can report some  
> progress in this area very soon.
>
> ---Rotan.
>
> ________________________________
>
> From: Andrea Trasatti [mailto:atrasatti@mtld.mobi]
> Sent: Sat 14/07/2007 20:42
> To: public-ddr-vocab@w3.org
> Cc: Rotan Hanrahan
> Subject: Re: Supported image types
>
>
>
> The "Measurement" field speaks about image types and sub-types and
> presents the example of JPEG compression. It also says: "The
> mechanism for describing image sub-types (for example progressive
> JPEG images versus baseline JFIF) will need to be defined by the
> DDWG" and this of course suggests that we should go down to a deeper
> level of detail than just "JPEG is supported".
>
> Of course we can discuss what is core and what is not. I think that
> even if we will eventually agree on just going with "JPEG is
> supported" it would not be smart to use a data typing that will
> prevent very well expected extensions such as "is compression
> supported", "is transparency supported", etc.
> I support the idea of keeping it "core", but  let's not just cover
> our eyes and use the experience that people like you, Rhys, Pontus,
> etc have on very well detailed databases.
>
> - Andrea
>
> Il giorno 14/lug/07, alle ore 14:14, Rotan Hanrahan ha scritto:
>
>> The information maintained in our commercial adaptation solution is
>> far more complex than the simple suggestion indicated, out of
>> necessity. I therefore have similar concerns. However, I note that
>> the property is "supported image types" and thus appears to suggest
>> a high-level view of what is supported, rather than a deep
>> description of support constraints (e.g. animation, multiple
>> layers, alpha channels etc etc). For the most basic of content
>> adaptation it may be enough just to know if you can use GIF or
>> JPEG, so I'd describe that as "core knowledge". Making sure you
>> choose the right colour combinations, depth, compression etc is a
>> level of detail beyond just basic adaptation, so I'd question if
>> this is core.
>>
>> ---Rotan
>>
>> ________________________________
>>
>> From: public-ddr-vocab-request@w3.org on behalf of Andrea Trasatti
>> Sent: Fri 13/07/2007 21:28
>> To: public-ddr-vocab@w3.org
>> Subject: Supported image types
>>
>>
>>
>>
>> There was a submission about Supported Image Types [1].
>>
>> I totally support the idea of a list of supported media formats and
>> images are certainly on top of the list.
>>
>> I disagree on the suggested type, which reads:"The property is an
>> unordered set of strings". I would rather suggest a list of
>> properties for every image type and subtype and use a boolean type.
>> This should be managed much more easily by developers and adaptation
>> softwares. I suspect that an unordered list (as suggested in the
>> Measurement field) will result in a long list hardly understandable,
>> I cannot imaging how sub-properties such as the loop function in an
>> animated GIF will be described in such a list, mixed with compression
>> factors, transparency and so on.
>>
>> Everyone knows how this is managed in WURFL (exactly as I suggest),
>> but I'd be curious to know how commercial products manage this, if
>> you can share it.
>>
>>
>> Andrea Trasatti
>>
>> [1] http://www.w3.org/2005/MWI/DDWG/wiki/
>> CoreVocabularySubmissions#head-611f3832c41c44c8cedaa35cb98b1fc7ca1f39 
>> 3
>> c
>>
>>
>>
>
>
>

Received on Sunday, 15 July 2007 22:32:40 UTC