RE: Supported image types

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

Received on Saturday, 14 July 2007 20:31:30 UTC