International Workshop on the Implementation of a Device Description Repository: Minutes [DRAFT]
12-13 July 2006
The minutes presented here were recorded in real-time by volunteers from the workshop participants. These people are not professional minute takers, and they were also actively participating in the discussions. Consequently, the minutes in this document should be viewed only as a representative sample of the discussions. Some errors and omissions are inevitable. Minor corrections to the original text have been made to account for mistranslations or mistranscriptions. The DDWG extends its gratitude to the volunteer minute takers.
- Rotan Hanrahan, MobileAware
- Edouard Marques, France Telecom
- José Manuel Cantera Fonseca, Telefónica Investigación y Desarrollo
- Enrique Varela Couceiro, Zandan
- Bennett Marks, Nokia
- Andrea Trassati, WURFL
- Ronan Cremin, dotMobi
- Stéphane Boyera, W3C
- Yoram Zahavi, Flash Networks
- Masayasu Ishikawa, W3C
- Luca Passani, WURFL
- Bertrand Schmitt, Zandan
- Ignacio Marín, Fundación CTIC
- Rafael Casero, SATEC
- Cédric Kiss, W3C
- Martin Jones, Volantis Systems Ltd.
- David Sanders, Vodafone
- Daniel Appelquist, Vodafone
- Richard Nkrumah, Enough Software
- Pontus Carlsson, Drutt Corporation
- Chris Abbott, Mobile Phone Wizards AS
- Njal Hansen Wilberg, Mobile Phone Wizards AS
- Toshihiko Yamakami, ACCESS
- Martínez Jose Angel, Technosite
- Dan, Stéphane, Andrea, Ronan, Cédric, Rotan, ...
- Day 1
- Day 2
- Summary of Action Items
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
... 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
... 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
... 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
... 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.
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
... 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]
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
... 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 :
... 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
... 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
... 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
Luca: you are adding too much
... 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
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
<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
... 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
... there should also be some administration system to add information to some node and get the information spread
Dave: this is a DD
... 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
... 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
... 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
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)
[End of day 1]
(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
[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
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
... 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
[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:
- Best practices
- 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
Bennett: Many man/machine and UI
issues with phones are similar those problems we have on the
... 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
... 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
... 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
... 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?
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
... 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
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
... 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
Rotan: after some talks with the
participants, I would like to start talking about the nature of
... 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
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
... 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
... 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
... 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
... 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
... Also, we should do something that will not break everything in the future
Bennett: jumping back to the
... 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
... 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
(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
... 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
... 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.
- 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 firstname.lastname@example.org
... thanks everyone for attending the Workshop
... thanks T I+D for excellent host
[NEW] ACTION: Bennett to review DD-landscape and send his comments [recorded in http://www.w3.org/2006/07/12-ddwg-minutes.html#action01]
[End of minutes]