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

I think that as a matter of principle and as defined in the charter of the group the API should be extensible.

It's essential, I think, that the API should be able to retrieve property values for the device and browser both separately and together. I think it follows that in general this means the API should allow retrieval of property values for the DC (when this is construed to mean the device, browser and any other gubbins that is in the way), the device alone, and unstandardised components of the delivery context that we are aware of but don't choose to recognise in this phase of work.

I don't think we need to work on this today, but the API should reflect this general direction.

Jo


> -----Original Message-----
> From: public-ddr-vocab-request@w3.org [mailto:public-ddr-vocab-
> request@w3.org] On Behalf Of Rotan Hanrahan
> Sent: 03 October 2007 20:32
> To: Andrea Trasatti; José Manuel Cantera Fonseca
> Cc: public-ddwg@w3.org; DDR Vocabulary
> Subject: 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:59:05 UTC