Device Description Repository Workshop, day 2 -- 13 Jul 2006

<ronan> ScribeNick: ronan2

<scribe> scribenick: ronan2

<scribe> scribe: ronan2

<sboyera> ping

Rotan recaps some activities to date

DDR -- where does its scope end - what information should be in it

If DDR is extensible, others can add to it

But our scope is really the browser characteristics

It is important that the architecture does not preclude extensions

We have to balance expediancy with practicalities

Would be good to get something working as soon as possible, and extend as appropriate

Mapping different pieces of information from different contributers could be a challenge, but it is important that we support this

But it is important that the DDR can be seen as a single repository

An important use case is the input of new information

How to label the trust associated with this information

A federated approach for information should give scalability

The W3C will produce a recommendation -- it is not a standards body, though the recommendations carry the weight of standards

Along with a recommendation should come a proof that what has been recommended will work

The recommendation could be just that or we could actually make recommendations of interfaces, along with proof of concepts

scribe: with real data behind it

DD version 2 may cover this

Some have suggested that the basic info in the DD would be something that could be contributed from WURFL, OMA etc

The other participants could use this as seeding activity and validate against their own data

This would be starting core of data for DDR

We have already discussed what we consider to be the basic required information for basic adaptation

scribe: about a dozen attributes

Where this info actually resides is open for debate

There is a link to the OMA liasion statement on the DDWG home page

<mimasa> cf. http://member.openmobilealliance.org/ftp/Public_documents/TP/Permanent_documents/OMA-LS_0122-to_W3C_MWI_re_Device_Description_Respository-20060712-A.zip

We now need to lay out the charter for the next tranche of work

The DDWG is a MWI initiative, so this should be our primary concern

<mimasa> ScribeNick: ronan2

Edward: raised an issue yesterday about whether this is limited to mobile browsing

Rotan: The DDWG is a MWI initiative, so this should be our primary concern -- but we should not preclude non-mobile use cases

Telefonica presentation

Presentation is about DDR design and implementation

Given by Jose Cantera

The technology around the repository is as important as the repository itself

scribe: but it is important not to reinvent the wheel

Seemless integration with existing standards is very important, but there will be a need for new mechanisms

Both UAProf and WURFL have some limitations

E.g. UAProf lacks mandatory attributes

WURFL lacks a central repository

WURFL also lacks warranty and update notifications

The DDR architecture should be open and extensible

<mimasa> ScribeNick: ronan2

<sb2> ping

The DDR could solve the problem of having to copy WURFL files to multiple machines

Proposes distributed federated model where different organizations maintain different chunks of information

But all the complexity hidden by a set of standard APIs

It is important that applications can override attributes

<ronan3> * I got kicked off

<ronan3> scribenick ronan3

<cedric> ScribeNick: ronan3

Versioning of the data is important

It is very important to support interop between the different repositories - e.g. a standard XML export format

There should be support for multiple different ways to provision new devices

Workflows will need to be defined around this

There could be a model for pay-per-use

scribe: associated with private device descriptions

DDR security model should support a number of use cases

Anonymous users, premium users, provisioning user, validating user, data manager

DDR validation and trust

Validation means ensuring that the device description is correct

Data should not be made public until it is validated

DDR APIs and tools

OMG IDL should be used for the APIs

Interfaces should be described WSDL

Design of the APIs should be aligned with existing DIWG work

There would probably be a set of web tools to manage this

Relationship with OMA & UAProf

Provisioning level data should be compatible at a minimum

Reference Implementation

Should be open source project

Telefonica are committed to be involved in this

MORFEO project can be used

Rotan: W3C has not done this before, but it certainly is possible that we could do this as open source project

Presentation ends

<DKA> q

<sboyera> qplus

Andrea: you said device inheritance is needed -- why is this?
... thinks it should not be a requirement even though it was successfule for WURFL

Jose: requirement is that the provisioning model is as easy as possible

<sboyera> [any plus enable person can add Dan and i in the queue ?]

Andrea: as long as you have the device info in your repository, the admin can easily link related devices

<DKA> q\

Andrea: device clustering -- if there is a model with no inheritance it will be easy to build device clusters

<sboyera> [good try dan, i tried already]

Andrea: inheritance is often a technical barrier

<sboyera> [i tried lso opera and IE, this is not a problem related with the browser]

Jose: without inheritance how can your API indicate hierarchy of devices?

Andrea: thinks that inheritance does not solve this problem

<DKA> q ±

Jose: inheritance and clustering are different

<sboyera> qctrl-177

Jose: Branches and grouping are different

Andrea: inheritance tree does not work e.g. some Samsung phones have the Nokia browser
... this would not easily be covered by inheritance

Rotan: proposes that we address this work as second charter

<bmarks> q bmarks

Chris: says that inheritence should not be part of the model - encourages people not to put data in
... any query is automatically a cluster - cluster does not need to be explicitly part of the model

DKA: Expresses support for Telefonica vision and method (open source framework)

<Rotan> (Note we are having queue management problems because of the lack of a + symbol.)

DKA: Would support this initiative if it happens with developers

Luca: I invented inheritance in WURFL but it has been double edged sword
... WURFL willl introduce modules to avoid multiple inheritance problem
... API should not rely on fallback mechanism to be there

Andrea: how can you do this? Voda imposes its own specidications on J2ME specs for example
... these families are specific to you -- may not be of use to anyone else

sboyera: The application is what decides the 'family', not the repository

Luca: doesn't understand why this belongs at API level
... it's important to provide just one way to do things

Rotan: need to discuss this in 2nd charter

bmarks: these are implementation issues -- not a good use of the group's time at this point

sboyera: What is missing is technology of indexing -- what do we use to index the information? UA string?

<Andrea> I also wanted to ask what Jose means by "Device deprecation". Did he mean "deprecation of device description"?

sboyera: The vocabulary will cause a problem - how can we unify the properties beyond the initial 15 or so

<Andrea> Lastly, why couldn't an open-source implementation provide signed DD's? If the open-source can establish a process, then DD's can be verified

Jose: the W3C will not define the extensive vocabulary -- this will be done by OMA etc

<Rotan> Observation, clustering can be external to the data (just like semweb annotation). Just an idea.

Dave: what is the difference between the Telefonica vision and the current requirements? Seems like the vision is beyond current requirements? Are there any gaps?

Jose: there may be gaps in provisioning, security and pay per view aspects of vision

Dave: need to have requirements updated for charter 2

Next presentation commences

Presentation by Technosite

"Strategies for tailoring web content for specific devices"

Disabled users have many problems with web access on mobile devices

Propose 2 solutions

1) Best practices

2) Device descriptions

<bmarks> q bmarks

List of best practices presented

DDR should help adapt content to mobile devices and assistive technologies

DDR should include accessibility/usability information

There are h/w and s/w aspects to this

Some assistive hardware and software solutions mentioned

Summary: it is important that the DDR takes into account assistive technologies
... the needs of users with diabilities should be be considered

Presentation ends

bmarks: Many man/machine and UI issues with phones are similar those problems we have on the PC
... We are talking to a community that has to deal with the same issues - some of these issues will already occur in DD
... It's a smaller increment in the mobile environment than in the PC environment
... the question is how to best describe the technologies that are already being applied
... There are other motivations for solving these problems in the mobile space that create synergies
... the data should fit fairly well into the visions that have been described

<Zakim> Rotan, you wanted to ask if accessibility community would maintain a ddr node with accessibility info

Rotan: if the DDR is distributed, with multiple contributers, could we have a node of the DDR that contains the accessibility information -- question to presenter
... will the accessibility community use such a feature?
... we don't care where the data comes from as long as we know we can trust it

ping

Jose: do you know the set of capabilities that will be needed for disability information? Will there be a module in vocabulary that will be devoted to this?
... are there specific attributes that are related to accesibility?

<nacho> q

Rotan: WAI has published guidelines in this area, but there is no machine readable information that would help adaptation

Nacho: we should liaise with WAI

Rotan: this information is useful only when it is in a node in the DDR
... perhaps some agencies would populate this node and sponsor it

<nacho> [plus sign worked for me yesterday but not today... weird]

Rotan: if we imagine that DDR exists, how does an author know what the properties mean? How does the authoring tool make sense of this? How do you get human readable information out of the DDR?

Luca: you read the implemetation from a website

<Andrea> [it seems to me like Ronan is filtering the minutes]

<sb> test

<Andrea> sb, you work

Luca: documentation could be in XML, tools could import this

Rotan: should there be mechanism for adding international descriptions

Dave: let's walk before we run

<jcantera> http://win.mpwgateway.net/MPWServices/soap.php

bmarks: had a similar problem with UAProfs and semantics

<Andrea> jose, nuSOAP is not a full SOAP implementation. Unfortuntaly lacks some important things

bmarks: as long as you have a semantic contract you allow the market place to layer on the extra stuff later
... it would be a mistake to build this into the system -- it can be built on top
... these are business opportunities that may come later, not something for the w3c

Rotan: but what about an English description?

bmarks: It's more important to establish the machine readable semantic contract

Rotan: the meta data describes the data -- the meta meta data describes the data to a human, perhaps in an authoring tool

When you get to 100's of attributes, the problem becomes serious

Rotan: question about Telefonica presentation -- exporting the data from a node -- what about all the relationships in the data -- would you expect this data to be exportable?
... If the data is a black box, the hierarchy information might not be useful to anybody else -- another node
... the XML format inherently has the hierarchy built into it
... would you expect the meta data relationships between the nodes to be exported?

Jose: thinks that the meta data should be exported

bmarks: There is easy way to agree on flat node definition
... there was a similar issue with UAProf -- they agreed that each node was standalone
... This makes the data very big
... You can't know a priori how the data will be used

<Rotan> Nice phrases - "exportable single unit" and "atomic unit of export"

bmarks: So you have to go through the process of defining the atomic unit for export, otherwise it'll all fall apart

<Andrea> +1 to Bennett

bmarks: For machine readbility, the contract needs to travel with the node

<sb> +1 also

bmarks: UAProf wa criticized for verbosity but not for technical issues -- this is not b/w sensitive
... Recommends that we don't try to manage the hierarchy
... This is a business opportunity

Luca: agrees with bmarks
... We should stick to the API .. ignore the underlying implementations
... Leave to each implementor how they want to model internally

Rotan: surface level export is enough]

Break for coffee

<Martin2> test

Mobile Phone Wizards presentation

<asamim> ScribeNick: Andrea

[thanks mimasa]

njal: wanted to develop a service that would require 3 lines of code to integrate
... real-time header analysis is key for us
... would like to see the DDR as a definition of the box, but not what is inside

Chris: understand the customer. Provide a PDF if the customer wants it, even if the device does not currently support it. The customer might install the acrobat reader later

njal: our repository automatically updates itself
... no need for update/batch procedures
... provide may interfaces such as SOAP, POST, .NET

Chris: admin interface allows for sync between different nodes
... ability to resell access to the system

njal: currently running on 4 main servers, 3 in Bergen, 1 in USA

Chris: clients can rely on our servers or might want to have a local server for performance reasons, for example
... the server is proactive in gathering device information
... most common devices go to the top automatically

Bennett: how do you create profiles?

njal: we do no testing. Sources are UAProf and getting on internet to get information

Chris: try to make sure device info is correct, but don't have connections with manufacturers, for example

Bennett: how many capabilities do you list?

Chris: 200-300

njal: when a new profile is detected in one of the servers, there is no need to search for it. gets added automatically

Rotan: can you query if the data you're getting is data verified by you (Mobile Phone Wizards)

Chris: there's a bit that says if data is from manual insert or automatic
... you can query the "manual DB" or the automatic DB
... you can query about a device or a specific device capability

Bennett: when you index a device to a profile, how do you do the matching? 1 to 1?

Chris: what I call an instance of a phone is the sum of all the HTTP headers
... not necessarily all device of the model will match that instance
... sessions tend not to change in time
... we calculate the profile once and cache.
... we have a lot of fields that will tell you is_series_60, is_xhtml, is_wml
... seem really useful to us
... tries to identify the browser and separately the JVM, for example
... tries to identify the different software parts of the device

Luca: supporting a certain mime type does not mean the full support. xHTML is a good example, its support does not mean tables are supported

Chris: we try to be very conservative

Bennett: there is a lot of alternative about how you create data. Real testing, reading documentation, etc.
... this all goes down to the trust metrics

Chris: there is a trust system in our solution that is about how we get the data

Bennett: algorithm can be very powerful, but there can always be some kind of exception

Chris: geo-location service. We cache ip ranges to make this faster

Rotan: how do you see yourself in this working group?

njal: we would be happy to see a standard, but also fear the standard might be too different from our existing architecture

Rotan: there is certainly a lack of standard in this field

njal: I think we should start with standardizing the interface or might get into a work that is too big and too far in the future

Rotan: your service seems like a live proof of concept
... thank you for the presentation

WALL overview

Luca: this was not a planned introduction, but seemed like there was an interest

(Rotan gives some extra cycles to his computer)

Luca: WURFL could be considered by some as UAProf on steroids

Bennett: someone else might think it's castrated UAProf

Jose: do you think this satisfies all the needs?

Luca: WALL is for people who don't know much about mobile or even nothing. They take WALL, build this HTML-like pages and WALL takes care of everything
... if you are an operator or a big portal, you do it on your own
... or take WALL as a basis and extend

jose: how about pagination? CSS?

Luca: that's a feature that should be added in the future
... on the other side, picking different CSS's, I thought about it, but never made it, because I think there are other ways to do it and not bind it to WALL and WURFL
... JSTL gives you all the tool you need, for example

Jose: maintaining a lot of if, then can be a pain

Luca: correct, but WALL already takes away a lot of the complexity

Rotan: ok, thank you Luca
... WALL is not so different from the DISelect features

open Debate

Rotan: after some talks with the participants, I would like to start talking about the nature of the DDR
... single database? WURFL-like, for example
... feature requirements seem to actually aim for a framework where more entities can contribute and not a single central service
... we should think about this framework
... a federated DB can be a solution
... provides the feature of multiple contributors
... also brings conflicts that will need to be resolved
... would provide the advantage of accessing different points of access, not a single place that might become unreachable
... should we talk about this framework or should we limit our discussion about the communication interface?

Stephane: if you want to work specifically on the API, then yes. If you want to consider an entire node, then you will need to talk the entire architecture

DaveS: I think it's important that we agree that we are not going to build a new database within the W3C
... there are already existing realities such as WURFL that could be a node of this federated system
... I think we need to clear up that we are not going to collect all the available data and make a new DB

Rotan: right

Stephane: are you against the idea of working on the basic idea of working on the basic properties

DaveS: that's a different question. The prototype and the data collection are not the same
... work on the 5 properties does not mean we are working on the database
... the 5 properties should be in the next charter. Take WURFL, UAProf, etc and identify these properties
... We support the idea of feeding an open-source initiative

Bennett: I think we're confusing the vocabulary issue with the creation on the database
... if you want to get into the business of the vocabulary, that does not have anything to do with "storing" it
... if you get into the business of HOW architecture should look like, then I start having a problem with that.
... I don't think the W3C is place to talk about how people should manage and scale data

Rotan: my concern is that it should be clear that this repository is not replacing other existing ones

Bennett: when you are describing a communication interface or protocol, you are not saying anything about how you store data
... different things

Luca: agree with Bennett and Dave 100%
... we should work on the API and leave the rest to the implementors. Otherwise we will fight against other W3C technologies and OMA, etc.

Bennett: at the past. CC/PP tells you how things should move around

Luca: let's be practical

<sb> q

Bennett: the word Repository gives a certain idea
... while here we are talking about the Device Description interface/protocol/access system
... we are not talking about _storing_
... not the physical database
... maybe the big problem you have is the original use of words

Rotan: that's probably true

Stephane: I have a different feeling.
... the use of words is a consequence of the Barcelona Workshop
... a need for a DD repository was described
... the need described was that we did not want a big repository that would replace existing ones, but that a place where basic device properties would be gathered

<DKA> qplus

Yam: it could have been a Device Descriptions Framework

Stephane: Dan was there, what is your feeling

Dan: first I want to say that the API should be a keyword in the re-charter
... it needs to be established and draw consensus around that
... and this is a separate issue if we should make a prototype, reference implementation or host the repository
... the API will still be a valuable thing
... and then the vocabulary
... do I still feel the need for the repository? Yes
... but it's still not clear to me who should build and run it

<sb> q

Bennett: I would propose that one thing seems clear to me, is that UAProf represents a place where the sematics formalism should stay
... there is no other place that captures the semantics
... whatever vocabulary you come up with, it should be an OMA work item

<nacho> q

Luca: it's ok that UAProf is where we agree on the semantics, but then this should not mean that UAProf should be the protocol
... API for developers should be simple

JuanJo: what about the syntax?

Bennett: that's another thing. UAProf went through a lot of problems such as case matching
... we have a lot of experience
... we need to have a single place where the semantics is agreed

Stephane: we are not talking about how you retrive data
... is this a topic we should work on?

nacho: I would like to comment about the architecture...
... key to the success to this is to have a simple API
... that gives to people a vision of the node
... and the API should be a request that lets me retrive a single DD or a set of DD
... and leaves to me the implementation
... and leaves to me the implementation
... I could query another DDR in the background and then deal with the results

Rotan: I think Luca wanted to say that the API should be the same when a client makes a request to the DDR and the API the DDR's use to communicate to each other
... Also, we should do something that will not break everything in the future

Bennett: jumping back to the import/export issuee
... thinking out loud
... if you agree UAProf is the definition of the semantics
... it seems to me that UAProf should be the transport method to communicate among DDR's
... UAProf could be the universal interchange system
... I think I propose UAProf as the format interchange system

<Rotan> The seed of DDWG - from the original MWI workshop - http://www.w3.org/2004/10/Oracle.pdf

Andrea: how do you see the UAProf vocabulary as compared to the one that this WG might come up with

Bennett: the original vocabulary was drafted in 1999
... and was supposed to evolve
... my own opinion is that it is now time to update it
... probably on the OMA side there is a lack of transparency in this process.

Andrea: your proposal for UAProf as an interchange system is about the structure, right? Not the entire specification

Bennett: correct, just the serialization

Jose: some information might get lost using UAProf because it is lacking some mechanisms to achive the full data we want to have

Bennett: I think this goes back to the discussion we had this morning. There seems to be a big disagreement
... on what data we will have
... in the DDR
... that needs to be agreed
... and then we can talk more about this

JuanJo: we really want to have the ability to export data from the repository and import it into another repository EXACTLY as it was before exporting

Rotan: session is over
... meet after lunch

DDWG Charter discussion

<Rotan> ScribeNick: Rotan

<asamim> (brainstorming)

(See summary doc that includes bullet points of items for inclusion in new charter)

Luca: could add metadata later in WURFL. We define api to retrieve info. Up to other reposositories to provide interfaces.

Quality and Trust costs money.

BM: There's the business op. Added value. Pay-for-trust...

Business ops come from creativity in implementations.

Luca: I see many "implementations" in the s/w industry. Many DBs implementing variations on SQL... etc.

Ambition - all freely given information should have some free DDR mechanism for getting this data.

BM: W3C should take proactive stand on the rules associated with access to data.
... Pay for value-add is OK.
... Perhaps to enforce it, the published data would have to come out "copyleft". Any work/derived work must also be free.
... But don't want to force the issue of defining a value add.
... People typically derive from UAProf, not use it directly.
... Layer 1, UAProf should continue to be free.
... Layer 2, should also be free.
... Value add higher up is a commercial thing.

<Andrea> #ddwg

BM: If manufacturer incurs huge cost for no obvious benefit, then manufacturer pulls out.

<Andrea> I think all this and Bennett's will to chat with us shows how much Nokia is ahead of other manufacturers pretending this is not interesting for them

<Andrea> And this means developers and companies will develop contents and services for Nokia phones FIRST and maybe for other manufacturers

Luca: if DDR not funded then it will never see the light.
... If we just keep it to API definition then I (WURFL) can implement it, and the commercial companies too.

<Andrea> Wouldn't it be great if Nokia not only exported their docs as PDF, but also as "DDR compliant format"?

<Andrea> Isn't it weird that SonyEricsson produces PDF's about their devices, but doesn't join this kind of activities?

MJ: Need to be careful not to enter into a copyleft situation where all derived info/processes must also be free

BM: Data available directly through DDR should be of the same level of freedom of access as the initial published data.

RH: Have to be careful not to extend freedom into value-add area or it will kill the commercial opportunities.

BM: Here representing Mom&Pop who will never be able to pay for such data.

Luca: which is why I think W3C could be asked to implement a node of the DDR to have this data.

RH: Steering Council anticipated a possible cost associated with this work, such as hosting a node.
... Commercials invoved to grow the market.

Brainstorming ideas will be summarised in final bullet points of charter ideas.

JC: Hard to mandate a policy in W3C.

RH: Especially if Rec is open, royalty free, means policy would have no teeth.
... Steering Council has also asked us to consider the role of the UA string.

AT: And need to consider separation of browser and device.

Luca: Perhaps use the entire set of headers as (part of) the key.
... Any info from the request used as part of the recognition process.

Chris: That won't work in practice. Headers changing over time, difficult to recognise the device just on headers.
... They change even during a single session.

BM: Would accept that header scanning is just a best-effort recognition. A hack. The only one available today.
... This is not something that W3C should be pursuing.
... Those headers are not there to do what we want.
... Unlikely to get any new header installed. Years.

Luca: Up to implementer to decide what to do with the headers.

RH: Think we should a deterministic query.

BM: But need to consider at least two dimensions. Device and browser.
... If I install a different browser, the characteristics will change.
... Requirement is to separate out device from UA definition.
... Come up with objective algorithmic way to identify a device.
... The hacks have to be resolved with a real W3C-supported approach to device recognition.
... The SC is asking us to solve the problem.

Luca: could be a new header?

BM: But there are a whole lot of reasons why a new header might not be the answer.

Yam: And also the dynamic properties.

<Luca_Passani> +

<Zakim> Rotan, you wanted to suggest domain issue

Ed: Maybe we are too reliant on the HTTP protocols. What about streaming clients etc?
... Need to be open to other technologies.

Luca: we could have other ids for other things.
... we have UAProf header but not useful because not all devices have it, and dereference to useless data.
... Some manufacturers will never follow the technologies.
... Perhaps we should accept that hacking will continue in order to address this.

BM: So we get restricted because of sloppy manufacturers.

<Andrea> The bottom line, again, is that Nokia helps developers and companies, they will produce contents and service for Nokia. If the others don't, they will keep being number 2

BM: Have a clear policy (based in time) of update and versioning.
... If you do ongoing update of Top N properties you need to interlock with OMA.
... For example, an update each January 1st.
... People need to know what to expect.
... This is a lesson we learned in OMA.

<mimasa> Rotan: please send your comments to public-ddwg@w3.org

<mimasa> ... thanks everyone for attending the Workshop

<mimasa> ... thanks T I+D for excellent host

<mimasa> Workshop adjourned

- DRAFT -

Device Description Repository Workshop, day 2

13 Jul 2006

Attendees

Contents