See also: IRC log
<Andrea> Hola Stephane
<sboyera> Present Benett
<Andrea> [richard from Enough Software is present. doesn't have access to the web client, AFAIK]
<sboyera> Present pontus
<sboyera> Present Richard (Enough)
<DKA> ScribeNick: DKA
<scribe> Scribe: Dan
Rotan: Going to start the introductions.
[introductions]
Rotan: 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...
<sboyera> edouard marques - FT
Eduard: 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.
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.
<sboyera> jose: project name : morpheo
<Rotan> Enrique Varela Couceiro
<Rotan> Bennett Marks
Enrique: 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: 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]
Andrea: I am a consltant. 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.
<bmarks> WURFL
Andrea: 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
Ronan: 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.
Stephan Boyera
<Andrea> [Stephan or Stephane?]
<Rotan> Stephane
Stephne: W3C is here to develop the Web to its full potential.
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.
Mimasa: I am also working for W3C, based on Japan. I am a heavy mobile user myself.
<Rotan> Bertrand Schmitt
Luca: 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: 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.
<Rotan> Ignacio MarÃn
Nacho: I am from CTIC. We are part of the Mobile Web Initiative, also participating in the MWBP.
<Rotan> Rafael Casero
Rafael: We have developed services including our own device repository. We think a device repository will improve the user experience for the mobile Web.
<Rotan> Cedric Kiss
Cedric: I'm also from W3C. I've been involved since January this year in W3C. I will be working on next charter for DDWG.
<Rotan> Martin Jones
Martin: 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]
David: 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.
<DaveS> Dan has repsonsibility of mobile internet initiatives in Vodafone and also chairs the BPWG in MWI
<bmarks> BPWG needs DD info to support best practices statements.
<DaveS> This may also include information from OMA, e.g. base MIME types
<Rotan> Richard Nkrumah
Richard: 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.
<Rotan> Pontus Carlsson
Pontus: 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.
<Rotan> Chris Abbott
Chris: 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)
<sboyera> q
<sboyera> any idea why my plus got dropped ?
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 cusomers mostly do
not need this additional information.
... Our system is real-time as well.
<Rotan> Njål Hansen Wilberg
??
test
<Rotan> NHW: Want increased focus on device detection
Luca: I wanted to make it clear
what Openwave's postion is wrt WURLF. WURLF is not a
replacement of UAProf. WURFL builds on UAProf.
... Some companies might start with WURFL but then move to a
commercial system.
<Rotan> q bmarks
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."
q to talk on scope
q
plus key is not working.
<sboyera> same problem here
<sboyera> qplus
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.
<sboyera> thanks !
Rotan: The issues of semantics have been raised.
<Rotan> q
<Zakim> Dan, you wanted to talk on scope
Stephane: for dynamic properities 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.
Jose: 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.
<Rotan> (Coffee next!)
<Rotan> Dan: want this group to focus on the issues of browsing.
<Rotan> Dan: Scope helps us make architectural decisions.
[break]
Dan: Exensibility is also key.
<sboyera> Scribe: steph
<sboyera> ScribeNick:sboyera
edouard Marques
<Rotan> (Copies of presentation files will be circulated after presentations)
q on slide 6
<DaveS> On slide 6 is the proposal to do validation and verification?
i was first !
steph: don't understand left side of slide 6, validation and verif 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 kno why but thank you
don't understand the right side
3 different api for 3 repositories ?
dont we need just one
?
<bmarks> q
<bmarks> q bmarks
edouard: yes there is a bracket, one api
luca: automatic test ?
<bmarks> q bmarks
edouard: verifycation of format
of the data
... validation and not verification
dave: verification is important
edouard: open question on how to do verif.
dave: how to we achieve semantics in each rep.
?
and what are you new solutions ?
ft is developping a new solution or want to fix existing solutions ?
edouard: new solutions and not new technologies
<Rotan> FT wants standardised semantics with reliable information
bennet: that's why in hte charter it said "device desc. evolution"
<Rotan> BM: 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
steph: what is new is the hat, unification of exisiting repos.
edouard: dynamic properties, personnal setup,... should be managed by the op. 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
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 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
jose: the api is independent of the rep.
<Andrea> [developers download the XML and store it locally and then access data in real-time]
yes it is what i thought and thus bennett 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
q
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]
dpe ?
<Andrea> [device profile evolution, OMA spec]
q\
<bmarks> q\ bmarks
rotan: scoping is very important
luca: think that nacho point is valid
we need to clarify
jose: nightmare if different api for dynamic and static
<nacho> +1 to what andrea will say
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: addind 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...
Bennett: 3 dimensional space: dynamic properties, browsers and device
<Rotan2> What is our scope within this space of multiple info sources?
and we should scope in each dimension where we go
<mimasa> cf. cf. Client-Specific Web Services by Using User Agent Attributes: http://www.w3.org/TR/NOTE-agent-attributes-971230
<Rotan2> Ed: wants to consider highly dynamic vs occassionally dynamic properties.
edouard: dyn. properties : static properties which never change, semi-dynamic properties like installing a new UA, and highly-dynamic properties
<mimasa> s/cf cf/cf/
ed: 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 dyn. 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 informatoin (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 api : for developpers and for the ddr
access
dave: we have the api : query-response but not the other
rotan: we will review the req. doc later
bertand: we have 2 api, for developer api, and middleware api
2 very different set of stuff
bertrand: we are forgetting to speak about the objectives at the end f the WS
clear decision needeed: source of data, verification, public basic ddr
scribe:
we will have to take actions at te 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]
<mimasa> 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
daves: different actors in the chain come at diffrent time ?
bennett: yes, that's the missing part
rotan: yes, please write it down
<scribe> 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 barcelona WS
<Rotan2> (Lunch next)
the goal was to understand who is pyaing the cost and who is taking advantage
to avoid mismatch
hard to convince for indirect benefits and direct costs
at nokia
[food]
<Andrea> scribe: Andrea
DavidS: 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
<sboyera> qplus
<sboyera> thks Andrea for the plus-disable community
[I know you are a minority, but you still get the right to speak... sometimes... when I like that to happen. :D ]
<sboyera> :)
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
<bmarks> q bmarks
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
DKA: 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
Jose: 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
Stephane: 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
DaveS: 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
DaveS: 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?
Bennet: I don't think I have a
good answer to this question.
... in OMA when these possible conditions arose, they were
avoided.
<DKA> q
Bennet: 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
dka: 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
jose: 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
<steph> qplus
<Luca_Passani> q
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
Stephane: 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
... Steph 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
Steph: 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
Steph: 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
Daves: 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
<mimasa> cf. http://www.w3.org/TR/2006/WD-DDR-requirements-20060410/#reqs
Rotan: briefly, last year, in Boston we summarized the results of the questionnaire about device capabilities
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
DaveS: 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
Rotan: mapping what already exists to our list would be a first step, covering what already exists
<steph> (w3c member only)
DaveS: 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?
DaveS: how about W3C?
Bennett: what is here is already better of what was done for UAProf originally
DaveS: 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
DaveS: 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
DaveS: 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?
DaveS: 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
<mimasa> (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 MediaQueries, 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 MediaQueries are currently the same
Stephane: MediaQueries 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 MediaQueries. 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 MediaQueries 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
Jose: 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 from Telefonica I+D
<Rotan2> http://www.w3.org/2005/MWI/DDWG/workshop2006/papers/FranceTelecom/presentation.pdf
<Rotan2> OK, that's it, I think. :)
<Rotan2> http://www.w3.org/2005/MWI/DDWG/workshop2006/papers/MobileAware/presentation.pdf
<asamim> Agenda: http://www.w3.org/2005/MWI/DDWG/workshop2006/agenda
<asamim> We'll start at 9AM tomorrow
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/WURLF/WURFL/ Succeeded: s/HHW/NHW/ Succeeded: s/now/no/ Succeeded: s/otan/Rotan/ Succeeded: s/behing/behind/ Succeeded: s/with/within/ FAILED: s/cf cf/cf/ Succeeded: s/bmarks/Bennett/ Succeeded: s/interface/communication interface/ Succeeded: s/makes it/makes it hard/ Succeeded: s/WURFl/WURFL/ Succeeded: s/scribenick: Andrea/scribe: Andrea/ Succeeded: s/specification/specification?/ Succeeded: s/gues /guest / Succeeded: s/MERFEO/MORFEO/ Succeeded: s/Workshop ends/Workshop day 1 ends/ Found ScribeNick: DKA Found Scribe: Dan Found Scribe: steph Found ScribeNick: sboyera Found Scribe: Andrea Inferring ScribeNick: Andrea Scribes: Dan, steph, Andrea ScribeNicks: DKA, sboyera, Andrea Present: mimasa stephane Dan DavidS Ronan Andrea Rafael Jose Cedric Agenda: http://www.w3.org/2005/MWI/DDWG/workshop2006/agenda.html Got date from IRC log name: 12 Jul 2006 Guessing minutes URL: http://www.w3.org/2006/07/12-ddwg-minutes.html People with action items: bennett[End of scribe.perl diagnostic output]