International Workshop on the Implementation of a Device Description Repository: Minutes [DRAFT]

Introduction statements from participants

Rotan Hanrahan, MobileAware (position paper): Introduces self.
... our database which appears in a number of different formats is proprietary to us. We spend lots of time testing devices and accumulating information.
... That activity is a replication of effort between us and many others.
... More importantly, the mobile Web is not growing in the same way as the fixed Web. In the mobile space one piece of markup does not work on all devices.
... We believe that it should be possible for all people to create simple content for the mobile space. To that end we think there should be simple interfaces, etc...

Edouard Marques, France Telecom (position paper): We have a solution to adapt content which doesn't satisfy us completely. We are looking to set up a new solution that would solve the issues of the existing solution. We think this workshop will help.

José Manuel Cantera Fonseca, Telefónica Investigación y Desarrollo (position paper): project name : MORFEO
...We are working on device descriptions in OMA and W3C. Our interestes are to facilitate the development of mobile applications. We have a content adaptation product as an open source initiative. We recognize the need of device descriptions for content adaptation to take place.
... We are interested that both OMA and W3C would be coordinated and that maintains compatibility between the two.

Eric Fruhinsholz, Zandan (position paper): I am from Zandan, R&D director. We need not only information about markup language but how response is handled by the device to understand why things work on some devices but not others.

Bennett Marks, Nokia (position paper): I'm from Nokia. I'm also the vice-chair of OMA BAC MAE and former chair of OMA UAProf. Nokia's interest in this: we are quite active in producing UAProf profiles for every device we ship.
... we understand that UAProf has its problems. We hope that combining the learning that's going on in OMA and W3C we can apply some creative thinking here.
... one of the issues we're interested in here is that whatever we come up with here be inclusive.
... Some heavy-weight solutions tend to favor the major players. We also have to think about the small guy. Light-weight solutions as well as heavy-weight solitions. We're looking to see that the whole marketplace is represented.

Andrea Trassati, WURFL (position paper): I am a consultant. I have been working in WAP development since 1999. I started working with early WAP phones and have worked for the last 7 years on multi-channel services, Web, WAP, SMS. I also worked on content delivery.
... During these years I have seen a lot of need for the development of these mobile services. In 2002 I started work on an open source project to try to help to make it possible to identify a stable framework.
... In the early days everyone was doing their own service. Key problems were in device detection. You need to know what the device can do.
... I have worked in WURFL -- open source project running since 2002. We kept it simple by using XML. Integrated with Java, PHP, Ruby, Perl, Python etc...
... We track about 400 capabilities.
... Core team is myself and Luca Passani but we have a global community providing information.
... We have a site on sourceforge -- 100 downloads per day of the XML file.
... We have been active in DDWG and we would be happy to see the wg to continue working. We would like to see more contributors. We want to have more users, and a bigger ecosystem. We want to keep covering the needs of our users.

Ronan Cremin, dotMobi (position paper): I am from dotMobi
... We are not a technology company but we are supportive of ddwg
... Our stance on the repository is we would like to leverage existing information as much as possible.

Stéphane Boyera, W3C: W3C is here to develop the Web to its full potential.

Yoram Zahavi, Flash Networks (position paper): Flash networks. We are interested in the acceleration of content across mobile networks. We have our own repository. We would like to see as repository exist that contains as much information as possible. Having a trusted repository is crucial for us.

Masayasu Ishikawa, W3C: I am also working for W3C, based in Japan. I am a heavy mobile user myself.

Luca Passani, WURFL: I'm Luca Passani. I work for Openwave. I find myself in the unusal position of dealing with W3C because helped create WURFL. W3C came to us so here I am.

Bertrand Schmitt, Zandan (position paper): We have our own database with over 1000 devices and detailed information. Our position considering the workshop. We believe that the repository should have additional information from what would be required for content rendering, such as MMS, streaming, ringtones, DRM, etc... Because this is part of the full user experience.
... We believe that you need a trust authority to certify information. We think the wifi alliance is a good model. We need a central authority. Maybe W3C. Maybe dotMobi.

Ignacio Marín, Fundación CTIC (position paper): I am from CTIC. We are part of the Mobile Web Initiative, also participating in the MWBP.

Rafael Casero, SATEC: We have developed services including our own device repository. We think a device repository will improve the user experience for the mobile Web.

Cédric Kiss, W3C: I'm also from W3C. I've been involved since January this year in W3C. I will be working on next charter for DDWG.

Martin Jones, Volantis Systems Ltd. (position paper): I'm from Volantis. [presents from slides]
... I've been in the company from the beginning which was in 2000. The objective was bringing the Web to mobile devices. We have about 150 employees. We're active in W3C. We're keen on promoting anything that will help the market in terms of the Mobile Web. A free device repository could be seen as a threat to us but we also see a big upside to growing the mobile web as a market. Also there is lots of duplication of effort right now.
... Our software adapts services for tens of millions of end users. We have a proprietary database with over 3000 devices. We track over 500 attributes per device. Some information is uniqe volantis information that couldn't be expressed in a standardized way but have of it could be.
... Issues with DD sources: primary sources from device manufacturers and browser vendors are often missing, invalid, inaccurate, incomplete, inconsistent and/or inadequate.
... There is a need for an authoriative source of device information.
... having a standard dd helps us but also helps the market grow.
... [presents slide on thoughts on the proposed DDR]
... Key issues: scoping, authority, extensibility, trust. Device manufacturers should be the main but not the exclusive source of DDR content.

David Sanders, Vodafone (position paper): I work in OMA and 3GPP and have been working in the device descriptions working group. We have many operating companies. Each of these have different repositories which duplicate effort. I want to think about open source standards. How do we make a mind-shift? Trustworthiness of information is a key issue we need to think about.
... I'd like to see a lot more participation in the DDWG as well.

Daniel Appelquist, Vodafone (position paper): I have repsonsibility of mobile internet initiatives in Vodafone and also chairs the BPWG in MWI
... BPWG needs DD info to support best practices statements.
... This may also include information from OMA, e.g. base MIME types

Richard Nkrumah, Enough Software (position paper): I am from a small software provider in Germany. Our product is a framework for developing applicaitons.
... We have clients, widgets which can be styled with CSS. All of this is controlled by preprocessing. We are a big fan of open source technology. All of this is based on a device database of our own. We track information like what bugs the device have, etc...
... Our next step is to create an interactive device database so users can upload their own descriptions of devices manually or through midlets. Device descriptions can be reviewed and customers can download stable versions of these capabilities.
... offline access is important as well.

Pontus Carlsson, Drutt Corporation (position paper): Drutt does a lot of device testing to maintain its repository. There is a lot of duplication here. We need this information to be available in a public DDR in a trustable and extensible way. We have been a member of DDWG from beginning and we hope to contribute to the next charter.

Chris Abbott, Mobile Phone Wizards AS (position paper): I am from Mobile Phone Wizards. We just launched a publicly available device repository based on Web Services. We're an example of a small company you're trying to make the Mobile Web accessibile to.
... I have a content site that sells mobile content. In many cases you need to become an expert in order to deal with device descriptions. Everyone knows that UAProf does not go far enough. Even with some solutions such as wurlf you still need to know lots about the devices. We created a repository which can be queried using a web service.
... Our repository can be used for free.

<Luca_Passani> hi everyone. Sorry I was late. How do I add myself to the speaker queue? q+?

<sboyera> there is no queue mngt

<sboyera> let me add it

<Rotan> (There's no speaker queue until we have concluded introductions)

Chris: Accept header seems to be ignored because it's not accurate because many smart phones tend to hide their capabilities.
... We've tackled a lot of the problems that are up for discussion and came up with solution so we'd like to throw that into the pot.
... Why isn't Microsoft here?
... There are lot of Microsof users that have been left out of the loop -- we want to bring those people in as well.
... Necessity of trust in the data is proportional to the size of your client. A lot of programmers don't care if it's "verified" or just "mostly accurate".
... Most programmers would only use 5 maybe 10 fields out of hundreds available.
... As long as the information is mostly accurate then they can support most of the customers.
... For example, MP3 support. We have mp3 in our repository but not "how" these are supported.

<DaveS> Level of Trust in terms of available device information is a key discussion point for the workshop.

Chris: But our customers mostly do not need this additional information.
... Our system is real-time as well.

Njal Hansen Wilberg, Mobile Phone Wizards AS (position paper): Want increased focus on device detection

Luca: I wanted to make it clear what Openwave's postion is wrt WURFL. WURFL is not a replacement of UAProf. WURFL builds on UAProf.
... Some companies might start with WURFL but then move to a commercial system.

Luca: If we specify the API to the DDR.
... One last point about trust.
... The reason why WURFL is here is that we can bring the developer community to what we create as long as WURFL is part of it. But we cannot conflict with the open source nature of WURFL.

Rotan: The issue is you need to know what the trust is.

Dave: Two observations: We tried hard in the DD group not to focus on any particular implementations. We skipped around the trust debate. We are not saying that trusted data is a requirement.
... 2. we haven't got Microsoft and we haven't got a lot of terminal vendors here. We haven't got content developers or tool vendors. Whatever we do in the next 2 days we have to remember that these guys aren't here.

<DaveS> We need to consider Trust but we didn't discuss in detail

Bennett: 3 observations: In my mind there is a spectrum of models. Scope needs to be determined. Scope of UAProf is "user agent". If we are to say we are scoping ourselves to browser and browser type issues, that would drive us down a different route than "everything a device is capable of."

<DKA> q+ to talk on scope

Bennett: one of the things that made UAProf both forward looking and difficult was reliance on RDF. There is a huge smantic prooblem in bringing together the data in wurfl and the propritary databases. How do you deal with the semantics.

Rotan: The issues of semantics have been raised.

<Zakim> Dan, you wanted to talk on scope

Stéphane: for dynamic properties there are technical issues to solve. We were missing a unified repository. We all agree that dynamic properties are very important. But the first step is having a homoginized and standards-based repository for the static data.

<Zakim> Andrea, you wanted to talk about WURFL's original scope and current scope

Rotan: Issues we need to debate: What is the scope, what do we do with namespacing and dynmic properties.

Andrea: WURFL originally started with the scope of browsing but since 2002 the scope has become wider. We have more and more cabilities to track. Most of the participants said that the repository should be extensible. The point is that the repository should be extensible.

José: We think that this could be a good opportunity to set up a general framework for device descriptions. In the W3C scope the capabilities to be defined would initially have to do with browsing but could be expanded.

Bennett: the architectural decisions you will make based on that scope are different.

Luca: For us as WURFL it's OK both ways. We can focus on the mobile Web or more. My point is about the semantics. I started from the other way -- I want something simple. Screen width 174.
... UAProf and WURFL are at different levels.

Dan: want this group to focus on the issues of browsing.
... Scope helps us make architectural decisions.
... Exensibility is also key.

[break]

France Telecom presentation

<sboyera> Scribe: Stéphane

[presentation slide (PDF)]

by Edouard Marques

<sboyera> q+ on slide 6

<DaveS> On slide 6 is the proposal to do validation and verification?

Stéphane: I don't understand left side of slide 6, validation and verification can be done per repository, but don't understand validation from a set of repositories?

Edouard: Yes, the important part is validation, it may be hard to construct a profile from multiple rep. and check that

Rotan: difference between verification and validation

Luca: Thank you, don't know why but thank you
... don't understand the right side
... 3 different APIs for 3 repositories?
... Don't we need just one?

Edouard: Yes, there is a bracket, one API

Luca: Automatic test?

Edouard: Verification of format of the data
... validation and not verification

Dave: verification is important

Edouard: open question on how to do verification

Dave: how to we achieve semantics in each repository?
... and what are your new solutions?
... FT is developing a new solution or want to fix existing solutions?

Edouard: New solutions and not new technologies

<Rotan> FT wants standardised semantics with reliable information

Bennett: That's why in the charter it said "device description evolution"

<Rotan> Bennett: Want to build on existing material. Now message saying we would throw stuff away.

Rotan: super repository relying on existing rep.

Edouard: tricky part to unify existing solutions, but this is the objectives

Stéphane: what is new is the hat, unification of exisiting repos.

Edouard: dynamic properties, personnal setup, ... should be managed by the operator, and not public

<Rotan> Edouard: much more advanced now in mobile info than in fixed info.

Edouard: I think the framework may benefit not only to mobile

Njal: What is a device? What is the definition?

Rotan: Defined in the charter of the group:

A "mobile device" shall be interpreted as a Web-enabled device that is normally used away from fixed locations and has been manufactured specifically to be portable and usable while being moved. Typical mobile devices include Web-enabled cell-phones (mobile phones) and Web-enabled pocket-sized Personal Digital Assistants (PDAs).

Edouard: Our position is to extend this definition

Rotan: we are all working under an umbrella
... the MWI umbrella

Bennett: slide 6: interesting dynamic in the market : no DB used directly
... what are requirements?
... none of the data used on real-time basis
... processed before
... that's why update is that hard
... the info is not updated on real-time

Luca: WURFL is used that way

Bennett: Important point
... about real time
... need a business model behind the update

José: The API is independent of the repository

<Andrea> [developers download the XML and store it locally and then access data in real-time]

José: Yes it is what I thought and thus Bennett's point is right

<Andrea> [some even have automatic checking and downloading of the XML]

Debate

Nacho: static vs dynamic
... static things here today, would be dynamic tomorrow
... we should consider that

Rotan: If the property is static or dynamic, the query can be the same
... then there is eventing

Bennett: You are missing a point : where the info is coming from
... dynamic properties known only the device
... from architectural point, the device have to be included

<Andrea> [DPE spec; Device Profile Evolution, OMA spec]

<bmarks> q+ bmarks

Rotan: Scoping is very important

Luca: think that nacho point is valid
... we need to clarify

José: nightmare if different api for dynamic and static

<nacho> +1 to what andrea will say

<sboyera> q to say that it is so easy to consider the device as another source of device info

<nacho> [but taking into account that it will transparently will have to deal with it]

Bennett: add in a dimension : multiple browsers
... we should take into the picture
... we are ignoring the separation between UA and device

Chris: we solved this problem : different profiles, different instances of the same device

<Zakim> sboyera, you wanted to say that it is so easy to consider the device as another source of device info

Rotan: the UA string discussion should take place, use or not...

<mimasa> cf. Client-Specific Web Services by Using User Agent Attributes: http://www.w3.org/TR/NOTE-agent-attributes-971230

Bennett: 3 dimensional space: dynamic properties, browsers and device
... and we should scope in each dimension where we go

<Rotan> What is our scope within this space of multiple info sources?

Edouard: Wants to consider highly dynamic vs occassionally dynamic properties.
... dynamic properties : static properties which never change, semi-dynamic properties like installing a new UA, and highly-dynamic properties
... very difficult for highly dynamic
... for the snd type, operator getting the notice should be able to update the profile

<Zakim> Andrea, you wanted to say that the dynamic profile should not be a problem for the DDR "consumer", but the DDR should take care of it transparently

Andrea: Browser == a piece of software
... lots of things can be installed. We should separate the physical aspect of the device and the software capabilities

Luca: I think we should draw the line to not consider the dynamic part
... API yes, if we want to waste our time we should go in the dynamic properties

Bennett: I was not saying where should be the line, just defining the bound
... we have to understand the whole sace to make the reasonalbe decision

Andrea: The API should be simple, and the DDR should be able to find out the information (comm with the device and so on)
... we should focus on 10 or 20 properties and not go further and let the market do that
... I'm thinking of 2 APIs : for developers and for the DDR access

Dave: We have the API : query-response but not the other

Rotan: We will review the Requirements document later

Bertrand: We have 2 APIs, for developer API, and middleware API
... 2 very different set of stuff
... We are forgetting to speak about the objectives at the end of the Workshop
... clear decision needeed: source of data, verification, public basic DDR
... we will have to take actions at the end

Rotan: Yes, the aim to have a roadmap for the group (charter)

Richard: Important point: vocabulary.
... vocabulary means structure, whaich structure for the ddr ?

Luca: I understand the point
... but I don't see any exit
... but I think we should start with something practical

[end of debate]

Review of Landscape/Ecosystem

<mimasa> cf. http://www.w3.org/TR/dd-landscape/

Rotan: review of the dd-landscape

Bennett: missing in landscape: state that metadata need to be injected at different points in the delivery chain
... missing one dimension

Dave: different actors in the chain come at different time?

Bennett: yes, that's the missing part

Rotan: yes, please write it down

ACTION: Bennett to review DD-landscape and send his comments [recorded in http://www.w3.org/2006/07/12-ddwg-minutes.html#action01]

Luca: you are adding too much dimension
... a new dimension makes things far more complicated

Bennett: defining the problem is a key action, where we cut the line
... is another problem, but cutting the line without considering the problem in a whole is a problem
... and the landscape should take all the dimensions

Rotan: agreed

Bennett: lots coming from the Barcelona Workshop
... the goal was to understand who is paying the cost and who is taking advantage
... to avoid mismatch
... hard to convince for indirect benefits and direct costs at Nokia

(lunch break)

MobileAware presentation

<Andrea> scribe: Andrea

[presentation slide (PDF)]

Dave: OMA is working on a central source for UAProfiles

Rotan: Aren't there just a few files?

Bennett: I'd say about 100

Andrea: How many from Nokia?

Bennett: Probably half of them

Rotan: Thank you for the attention

Luca: What do you mean by adoption by specialists?

Rotan: Specialists like us, can't adopt your solution, but we aknoledge the existence of WURFL

<DKA> q to suggest open source vs. commercial software out of scope for this workshop.

Luca: I disagree about the non-easy integration. With open-source you can hack the software just make it work with your solution. Often commercial products are the opposite

Rotan: commericial entities don't agree on this. We think that if there was a common interface it would be easier to integrate with existing products

Dan: I don't want to get into the war between OSS and commercial

Rotan: I only said that it's hard to integrate commercial products and WURFL. If there was a common interface, then it would be easier

José: aren't you using open-source software in your software?

Rotan: yes, some things, such as DOM parser. But we some things can't be done at commercial grade. it's just pieces

Luca: no I see your point. You are saying that it is hard to integrate OSS into commercial products.

Rotan: the absence of an interface, then we could integrate OSS into a commercial product more easily

Luca: I can live with that

Stéphane: in my view in your picture of the DDR environment you're missing the "core repository" that should be open and freely available

Rotan: it's missing because I meant to say that the core repository can be any of the ones listed
... I was tempted to put W3C, but then did not

Dave: I think WURFL kinda falls into the proprietary source
... what do you think is needed to make the environment work?

Rotan: the gray arrows represente the queries. And generally you'll have a cache. And the red arrows represent the communication between the single DDR intances
... there should also be some administration system to add information to some node and get the information spread

Dave: this is a DD community.
... what about other entities?

Rotan: there are still some management issues that need to be addressed
... I don't see a single node as THE repository

Bennett: what you are implying in this diagram, you mean that the DDR should also take care of the distributed system
... this tends to be managed by big companies that ask for a lot of money for that
... and then I wanted to comment about the usage of this data for marketing purposes
... sometimes back, IBM, wanted to add capabilties about CSS in UAProf
... but some device manufacturers were worried that competitors would make 1-to-1 comparisons
... so marketing use can be a terrible disincentive
... a lot of data that could have been very useful never got into UAProf for these reasons

Rotan: I see your point
... but anyone someone's going to do it anyway

Luca: thanks for your story, Bennett. I think this confirms that UAProf should not be left to manufacturers

Bennett: what needs to be considered is that we should not build something that will give some power that he doesn't already has. If you build something that changes today's power, it will fail for political reasons
... validation, verification and certification are three very important activities
... WURFL is in a position in which you can do what you want, but when a standards body starts this kind of activity it will be taken into high consideration

Eduard: who is leading this power balance, in your opinion?

Bennett: I don't think I have a good answer to this question.
... in OMA when these possible conditions arose, they were avoided.

Bennett: with DM there will be a significant power change.
... and this is why it has never been really carried on
... So I would like you to keep this in mind

Dan: I am restating what Luca just said, but
... we should be aware of the problems that you identified
... if political issues are blocking innovation
... WURFL has been a disruptive innovation
... UAProfile.com has been a disruptive innovation
... even if this can be scary for Vodafone
... we will see the market continue to innovate in pools and not all together
... the group would like to create a cohesion

José: do you support the idea of a single file, in your architecture?

Rotan: any of the single nodes could be a single file, but what matters is that the communication interface is common

Luca: I don't like your architecture because there are local caches and these represent another repository itself
... in the aim of producing something useful for the community
... we should focus on what you represented as a local cache

Rotan: what I mean there is to cache the value of the screen size and not get on the network all the time to query the value
... it's a technical solution

Luca: even if it's simple, what is it?

Rotan: it's just a local cache of the query and their results
... it's only a performance mechanism

Luca: is your aim to be able to replace WURFL with MobileAware without a problem?

Rotan: that's our plan

Luca: how do the two repositories communicate? they have different vocabularies

Rotan: that's the semantics problem. We will work on it in step 2

Andrea: doesn't this activity show you (the manufacturers) that you should be more cooperative

Bennett: we are now being able to quantify the value of UAProf
... but it is not so easy
... and probably many others don't see that value

Rotan: manufacturers don't want to release information too early
... this makes it hard for us to be able to put the device description in our repository in time for the release

Bennett: device information is not going to be released until the public release of the device itself

Luca: but this goes back to my point of an external entity that will certify

Bennett: they would not get the device early, anyway
... honestly I don't think that this time problem is as big as the rest of the problems you identified here

Rotan: in my picture you can see there is a published specification box and that could be the manufacturer and with this architucture the data would be delivered faster

Bennett: certainly working with manufacturers will shorten these delays and the manufacturer knows everythin about the device, of course

Stéphane: this group could suggest a set of tests

Rotan: as soon as we will have a set of properties, we can work on the tests

Bertrand: I wanted to support Bennett's point
... the distributed system might be too complex
... we are running all kinds of tests, so of course manufacturers are the best ones to provide this kind of information

Rotan: wrt implementation we believe it could be done in phases
... once we have an agreed interface we can talk about the architecture and environment in a step 2

<Zakim> bmarks, you wanted to say something

Bennett: I hear very very different views of what is going to happen
... Stéphane is talking about a few hundred capabilities for a few thousand devices. That is not so big
... on the other hand, the image I hear from Rotan and others, they are talking about 500+ capabilities and multiple parameters and aspects for the same amount of devices
... API would not change, but the internal architecture would be completely different
... you NEED to decide what the internal architecture and scope is going to be now
... if you look at UAProf and WURFL, you will see a lot of data that is out of the scope of mobile web
... and those things will continue to be integrated
... and this is the opposite of the problem I saw this morning
... you are solving the problem you see nicely, but you don't solving the entire picture
... is that good enough?

Rotan: we would start with just a few properties for basic adaptation and then extend
... we don't want to do 1 API for basic info and 1 for advanced. It would cost money, we would like to have 1 API that does basic AND specialized
... there are small companies that would not have the resources

Stéphane: there is a difference between the architecture and running a service
... my feeling is that having the information available is different from running the web server to provide it
... I am not completely sure that a picture as complex as Rotan's is needed

Rotan: my picture could turn into reality in 10 years, but at least we can give something to the community soon, if we can provide a simple API
... we would like to remove the human interaction for a few things and replace it with automatic tools

Stéphane: API and vocabulary should not be mixed

Luca: in the future I see 5 basic capabilities with common names among different repositories and everyone extending their own way.
... I just want to make sure we talk about something real and not too visionary

Dave: Rotan, could you summarize the conclusions about device properties?

Rotan: I would like to talk about it at the end of day 2, which is tomorrow
... briefly, last year, in Boston we summarized the results of the questionnaire about device capabilities

Review of the DD Requirements

<mimasa> cf. http://www.w3.org/TR/2006/WD-DDR-requirements-20060410/#reqs

Rotan: some companies were scared that revealing the capabilities considered most important could be a thread for them.
... information was sent to Stephane privately and he released the results
... about 20 or 30 properties were identified for a basic adaptation
... that is the information that should be in the basic repository.
... other entities will add information they like and need for mobile perfect
... some of the properties are not part of UAProf
... who is going to provide that information

Dave: OMA discussed the addition of more properties
... and units, for example
... what is expected from UAProf and OMA?
... update the vocabulary?

<steph> link to the properties survey result: http://lists.w3.org/Archives/Member/member-ddwg/2005Nov/0041 (W3C Members only)

Rotan: Mapping what already exists to our list would be a first step, covering what already exists

Dave: Who is going to make the final decision about semantics and vocabulary? Is screen measured in pixel only?

Bennett: I think UAProf is in the best position at this time
... I am glad you had this discussion and captured
... this is what is needed, but will UAProf have enough horsepower?

Dave: How about W3C?

Bennett: What is here is already better of what was done for UAProf originally

Dave: Then we should identify the vocabulary and then ask UAProf, WURFL, etc to comply

Bennett: You probably need a public process and you need to have public hearing
... in UAProf anyone can suggest new tags, even if most people don't know it
... but then you need to have public hearing
... put together a process and get it going

Dave: Let's put together the process, and then the W3C will go to the OMA
... how does WURFL relate to this process?

Luca: That's what we came here for

Rotan: In WURFL there's a name for a property. What we need to do is identify it and map it

Dave: It seems like there's a lot of concern about this. This should probably be a priority for the group

Luca: WURFL was born as a tool. Later started to import UAProf and we think we will continue doing it

Bennett: Why bother, as long as UAProf is going to comply anyway?

Dave: We will identify some property names, WURFL should simply find a way to comply. Maybe change to those names

Luca: That's possible

Rotan: WURFL could actually make the communication interface compliant with DDR spec that does the mapping and leave the internal names as they are today

Bennett: Bag is a pain

Rotan: Thanks for your experience, this is what we need

(Rotan quickly goes through requirements)

Rotan: We don't have a charter for this group. Part of the activity of this workshop is to identify possible new items
... we will need to define the vocabulary
... and also identify how other internal things will be like
... the API's
... validation and trust
... trying to design the perfect solution might take years and not produe anything in the near-term

Luca: What I would be happy to hear tomorrow is identify those 5 capability names, talk about IDL and polish the requirements, of course
... trust could be an integer for now and think about what to make with it later

Bennett: As you look at other W3C activities such as DISelect and Media Queries, how much overlap do you see?
... and we are going back to the idea of where you inject the data. At what point of the process
... would be good to see how these might overlap other works in W3C

Rotan: DISelect and Media Queries are currently the same

Stéphane: Media Queries is for presentation and DISelect is for the layout

Bennett: But this confirms my suspect is that there is overlap and the position in process chain is important

Luca: I don't care about DISelect and Media Queries. They seem too complicated

Rotan: If someone builds an XPath to query WURFL you're done

Bennett: These could all be valid solutions to the same problem. W3C needs to rationalize
... each of these technologies can seem to complicated to you, not so complicated to others. They all seem to cover the same topic and need to be rationalized

(Rotan reviews the original charter deliverables and forecasted possible follow-ons)

Luca: What do you mean by reference implementation?

Rotan: I mean writing a piece of software that does what is described as the API's.
... could be something that works with Media Queries and DISelect
... yesterday we talked for example about servlets and the fact that Tomcat is the reference implementation
... this means that other implementations, to be compliant, will need to behave like Tomcat and not as you might interpret the specification?
... in the beginning I think a prototype should be enough
... people who's been lurking on the list, might start doing some real code

José: We have some worries about other reference implementations that have been done based on W3C recommendations. We think that this was valid for browsers and should still apply
... it could be an open-source project

Rotan: I was talking about this last night with Stephane. I think it's a good idea

Luca: WURFL could be a good candidate, it's a matter of resources

Rotan: That's true for probably all of us

(Workshop day 1 ends. MWI guest presentation about MORFEO-MyMobileWeb from Juan J. Hierro, Telefónica I+D)

(Scribe: Ronan)

(Rotan recaps some activities to date)

Rotan: 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
... 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
... 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
... We now need to lay out the charter for the next tranche of work

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

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

Telefónica presentation

[presentation slide (PDF)]

Presentation is about DDR design and implementation

Given by José Cantera

José: The technology around the repository is as important as the repository itself
... 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
... 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
... 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
... 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

José: DDR validation and trust
... Validation means ensuring that the device description is correct
... Data should not be made public until it is validated

José: 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

José: Relationship with OMA & UAProf
... Provisioning level data should be compatible at a minimum

José: Reference Implementation
... Should be open source project
... Telefónica 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)

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

José: Requirement is that the provisioning model is as easy as possible

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

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

Andrea: inheritance is often a technical barrier

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

Andrea: thinks that inheritance does not solve this problem

José: inheritance and clustering are different

José: 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

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

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

Dan: 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

Stéphane: 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

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

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

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

Stéphane: 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

José: 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?

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

Dave: need to have requirements updated for charter 2

Technosite presentation

[presentation slide (PDF)]

"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

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

Bennett: 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

José: 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?

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

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

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> [on behalf of Mobile Phone Wizards who have no IRC access] http://win.mpwgateway.net/MPWServices/soap.php

Bennett: had a similar problem with UAProfs and semantics

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

Bennett: 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?

Bennett: 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?

José: thinks that the meta data should be exported

Bennett: 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"

Bennett: 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

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

<sb> +1 also

Bennett: 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 Bennett
... 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)

Mobile Phone Wizards presentation

[presentation slide (PDF)]

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

José: 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

José: 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

José: 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?

Stéphane: 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

Dave: 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

Stéphane: are you against the idea of working on the basic idea of working on the basic properties

Dave: 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

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

Stéphane: 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

Toshihiko: it could have been a Device Descriptions Framework

Stéphane: 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

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

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

Stéphane: 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

José: 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

(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.

Bennett: 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.

Bennett: 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.

Bennett: 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?

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

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

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

Bennett: 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.

Rotan: MWI 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 summarized in final bullet points of charter ideas.)

José: Hard to mandate a policy in W3C.

Rotan: 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.

Andrea: 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.

Bennett: 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.

Rotan: Think we should a deterministic query.

Bennett: 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?

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

Toshihiko: And also the dynamic properties.

<Zakim> Rotan, you wanted to suggest domain issue

Edouard: 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.

Bennett: 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

Bennett: 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.

The following text containing suggestions for a new DDWG charter was evolved through a brainstorming session at the workshop. The evolving text was visible to the participants throughout the session. It was mentioned in the minutes and is included here for completeness.

Items for the DDWG 2 Charter,

• An architectural design (including trust model)
• A design for a reference repository of device descriptions A reference (prototype?) implementation of a repository
• A solution for aiding discovery of vocabularies and profiles. (forum?)
• A strategy for extending, distributing and delegating the repository where appropriate.
• A set of interface specifications for methods to access the device repository.
• Guidelines on the population and maintenance of device information repositories.

• A collection of values for core characteristics for a large set of devices
• Decision on running an actual repository (node)
• Definition of the namespace of core capabilities and process for extending it
• Administrative protocols (inluding import/export/archive formats)
• Administrative functionalities
• Security model(s) for access and administration
• Update of the list of "essential device properties"
• Definitions of categories/groups of device characteristics
• Establishing formal relationships with DIWG and the subgroup responsible for DCI
• Establishing formal relationships with OMA DPE and Vocab Mgmt activities
• Establishing formal relationships with WAI
• Inheritance and fallback/best-effort mechanisms (and issues of trust inheritance)
• Unique index for identifying the device, the context etc. (Role of User-Agent Header string)
• Versioning (implied in the DDR requirements)
• Clustering/inheritance within DDR data
• Should DDR node describe how it gets data? (Assumptions, direct testing, inferred, guesswork...)
• SAY SOMETHING ABOUT KEEPING FREE INFO FREE (DDWG should examine and then choose/support an option)
• PRINCIPLE: Ensure proposed solution works with real/legacy devices.

Achievable:

• Requirements doc to UAProf Vocab Mgmt activity in OM that specifies in satisfactory detail the top N properties. (Update the top N before we send to OMA.)
• Definition of DDR API (and required semantics)
• Call for prototype implementations
• Call for hosting of a permanent access point
• Policy statement on the management and use of DDR data
  • Example: the top N properties could be required to continue to be free via any system using DDR
• Requirements for unique device identifier and UA identifier.
• Establish a policy for ongoing update of Top N properties.

Anthing that falls into the "subjective" could be classed as "business opportunities". Eg. my technique for using the data is better than yours...

Management of derived data.

Focus on what is needed to get onto the Rec track. Issue: Quantification of Trust & Quality.
Can I discover from where the response got its information when I query the DDR?

Implementation within the black boxes should be out of scope. Charter must take into account all communities that will create/use this data. Can't have situation where everyone has to pay. There might be a risk if we ignore what is in the box. Must be a requirement for a common free base, regardless of what is inside. Cannot have situation where getting access requires payment for access.

Open Source (e.g. WURFL) could provide simple implementation of the API so that at least one free source of info is available.

When data is given for free (e.g. Nokia device profile) it should continue to be free even if it gets included within some other mechanism (e.g. a DDR interface). We should mandate that this free basic information continues to be available free through DDR.

Rotan: please send your comments to public-ddwg@w3.org
... thanks everyone for attending the Workshop
... thanks T I+D for excellent host

Workshop adjourned