RE: [VOC] Comments on the current version of the vocabulary

We should be careful not to assume that "device" means only the physical aspect of the client. The delivery context key is derived from a number of aspects of the client, potentially including both the physical and software aspects of the client. On this basis, the properties of the browser on the particular client hardware are potentially known in advance. In some browsers, the width of the scrollbar is fixed and known, and therefore (as it has an impact on width-based adaptation) it could be recorded in a DDR. For some browsers, the width might not be knowable, perhaps because of some user customisation of the browser chrome.

I believe that the usable width is something that is potentially a candidate for the DDR Core Vocabulary, so long as we refine the definition carefully. It must be the width of the window in the browser when the scrollbar is present, and only applies when this is not affected by chrome. Otherwise the value could be the default to use, in cases when you cannot be sure of the current width of the scrollbar.

I know of a proprietary repository that has this information, and I know that the information is quite useful. However, "quite useful" is not the same as "essential", and the Core Vocabulary should be focussed on essential properties. If there is a strong opinion that the property is essential, then I think it's right that it should be in the Core.

---Rotan.

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Andrea Trasatti
Sent: 03 October 2007 17:29
To: José Manuel Cantera Fonseca
Cc: public-ddwg@w3.org; DDR Vocabulary
Subject: Re: [VOC] Comments on the current version of the vocabulary


I agree that the "usable screen size" can be hard to measure and that  
a lot of factors can modify the result, especially if you think of  
scrollbars that appear only when needed.

I think that there's a mistake in your definition of which WURFL- 
capabilities are in the Browser scope or in the DC. In theory they  
are ALL part of the DC. For example you write the XHTML Basic support  
is a browser "feature", but that the preferred markup is part of the  
DC. I think that we should limit our scope to what is meaningful for  
the device and the browser and leave the DC to other groups or other  
initiatives. All of the properties that you listed are a property of  
the browser first and later of the DC. The browser might support  
XHTML Basic. A transcoding proxy might support XHTML Basic and  
convert it into WML 1.0 because your browser only supports WML 1.0.  
 From a server perspective you might never know it.

For the purpose of the Vocabulary we should limit ourselves to what  
is meaningful for the device. The DC, in fact, is built  on top of  
what the device (and OS and browser and network connection) can do.  
The full DC is a morphing beast that you can hardly manage as things  
are today.

I see a few options here (in no particular order):
a) we think "Usable screen size" is not meaningful for the Core  
Vocabulary, so we drop it as a group
b) we think "Usable screen size" is important, so we work on it
b.1) since it's a complex task, we can refine the definition, clear  
up what we mean
b.2) since it's not entirely in our scope we can define it better and  
limit OUR definition to what we think is in scope
b.3) it's fine as it is
b.4) we are ambitious and want to describe it better and extend its  
meaning in the Core Vocabulary


If you have more options on your mind you can add to the list.

- Andrea

Il giorno 01/ott/07, alle ore 16:38, José Manuel Cantera Fonseca ha  
scritto:

>
> Dear all,
>
> As a result of the analysis made on [1] here are the comments  
> (coming from me on behalf of the MyMobileWeb project) on the  
> vocabulary (some of them already known by Andrea, as I was chatting  
> with him on the MSN :) ):
>
> + Usable Screen Width / Height. If I read the description, this is  
> something that will depend on the whole DC and it will be likely  
> not suitable for storing in a DDR. The value of this property will  
> be calculated and not stored
> + MIME Types. Do we really need a MIME type property for each  
> technology, or do we need to associate an additional "subproperty"  
> MIME_Type to each technology?
> + ECMAScript: It is not enough with saying EcmaScript yes or no.  
> What DOM Level Support (if any) has this browser? That's it's  
> really important
> + UTF-8 Are we going to restrict to UTF-8, only, or we are going to  
> consider other charsets?
> + Table Support, how we are going to express that a device has  
> table support but there is a limitation in the total number of  
> columns that can be displayed?
> + Italic and Bold. I'm not sure if this properties are going to be  
> in such status, shouldn't be it implied by the version of XHTML and  
> CSS supported?
> + Caching I'm in doubt if this property may affect an application  
> regarding content adaptation
> + I'm missing properties regarding the preferred markup formats,  
> image formats, I will ask for them
>
> Best Regards
>
> [1] http://forge.morfeo-project.org/wiki_en/index.php/MyMobileWeb- 
> WURFL-W3C_Core_Vocabulary
>

Received on Wednesday, 3 October 2007 19:31:57 UTC