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-611f3832c41c44c8cedaa35cb98b1fc7ca1f393 
> c
>
>
>

Received on Saturday, 14 July 2007 19:43:13 UTC