See also: IRC log
<ronan> ScribeNick: ronan2
<scribe> scribenick: ronan2
<scribe> scribe: ronan2
Rotan recaps some activities to date
DDR -- where does its scope end - what information should be in it
If DDR is extensible, others can add to it
But our scope is really the browser characteristics
It is important that the architecture does not preclude extensions
We have to balance expediancy with practicalities
Would be good to get something working as soon as possible, and extend as appropriate
Mapping different pieces of information from different contributers could be a challenge, but it is important that we support this
But it is important that the DDR can be seen as a single repository
An important use case is the input of new information
How to label the trust associated with this information
A federated approach for information should give scalability
The W3C will produce a recommendation -- it is not a standards body, though the recommendations carry the weight of standards
Along with a recommendation should come a proof that what has been recommended will work
The recommendation could be just that or we could actually make recommendations of interfaces, along with proof of concepts
scribe: with real data behind it
DD version 2 may cover this
Some have suggested that the basic info in the DD would be something that could be contributed from WURFL, OMA etc
The other participants could use this as seeding activity and validate against their own data
This would be starting core of data for DDR
We have already discussed what we consider to be the basic required information for basic adaptation
scribe: about a dozen attributes
Where this info actually resides is open for debate
There is a link to the OMA liasion statement on the DDWG home page
We now need to lay out the charter for the next tranche of work
The DDWG is a MWI initiative, so this should be our primary concern
<mimasa> ScribeNick: ronan2
Edward: raised an issue yesterday about whether this is limited to mobile browsing
Rotan: The DDWG is a MWI initiative, so this should be our primary concern -- but we should not preclude non-mobile use cases
Presentation is about DDR design and implementation
Given by Jose Cantera
The technology around the repository is as important as the repository itself
scribe: but it is important not to reinvent the wheel
Seemless integration with existing standards is very important, but there will be a need for new mechanisms
Both UAProf and WURFL have some limitations
E.g. UAProf lacks mandatory attributes
WURFL lacks a central repository
WURFL also lacks warranty and update notifications
The DDR architecture should be open and extensible
<mimasa> ScribeNick: ronan2
The DDR could solve the problem of having to copy WURFL files to multiple machines
Proposes distributed federated model where different organizations maintain different chunks of information
But all the complexity hidden by a set of standard APIs
It is important that applications can override attributes
<ronan3> * I got kicked off
<ronan3> scribenick ronan3
<cedric> ScribeNick: ronan3
Versioning of the data is important
It is very important to support interop between the different repositories - e.g. a standard XML export format
There should be support for multiple different ways to provision new devices
Workflows will need to be defined around this
There could be a model for pay-per-use
scribe: associated with private device descriptions
DDR security model should support a number of use cases
Anonymous users, premium users, provisioning user, validating user, data manager
DDR validation and trust
Validation means ensuring that the device description is correct
Data should not be made public until it is validated
DDR APIs and tools
OMG IDL should be used for the APIs
Interfaces should be described WSDL
Design of the APIs should be aligned with existing DIWG work
There would probably be a set of web tools to manage this
Relationship with OMA & UAProf
Provisioning level data should be compatible at a minimum
Should be open source project
Telefonica are committed to be involved in this
MORFEO project can be used
Rotan: W3C has not done this before, but it certainly is possible that we could do this as open source project
Andrea: you said device
inheritance is needed -- why is this?
... thinks it should not be a requirement even though it was successfule for WURFL
Jose: requirement is that the provisioning model is as easy as possible
<sboyera> [any plus enable person can add Dan and i in the queue ?]
Andrea: as long as you have the device info in your repository, the admin can easily link related devices
Andrea: device clustering -- if there is a model with no inheritance it will be easy to build device clusters
<sboyera> [good try dan, i tried already]
Andrea: inheritance is often a technical barrier
<sboyera> [i tried lso opera and IE, this is not a problem related with the browser]
Jose: without inheritance how can your API indicate hierarchy of devices?
Andrea: thinks that inheritance does not solve this problem
<DKA> q ±
Jose: inheritance and clustering are different
Jose: Branches and grouping are different
Andrea: inheritance tree does not
work e.g. some Samsung phones have the Nokia browser
... this would not easily be covered by inheritance
Rotan: proposes that we address this work as second charter
<bmarks> q bmarks
Chris: says that inheritence
should not be part of the model - encourages people not to put
... any query is automatically a cluster - cluster does not need to be explicitly part of the model
DKA: Expresses support for Telefonica vision and method (open source framework)
<Rotan> (Note we are having queue management problems because of the lack of a + symbol.)
DKA: Would support this initiative if it happens with developers
Luca: I invented inheritance in
WURFL but it has been double edged sword
... WURFL willl introduce modules to avoid multiple inheritance problem
... API should not rely on fallback mechanism to be there
Andrea: how can you do this? Voda
imposes its own specidications on J2ME specs for example
... these families are specific to you -- may not be of use to anyone else
sboyera: The application is what decides the 'family', not the repository
Luca: doesn't understand why this
belongs at API level
... it's important to provide just one way to do things
Rotan: need to discuss this in 2nd charter
bmarks: these are implementation issues -- not a good use of the group's time at this point
sboyera: What is missing is technology of indexing -- what do we use to index the information? UA string?
<Andrea> I also wanted to ask what Jose means by "Device deprecation". Did he mean "deprecation of device description"?
sboyera: The vocabulary will cause a problem - how can we unify the properties beyond the initial 15 or so
<Andrea> Lastly, why couldn't an open-source implementation provide signed DD's? If the open-source can establish a process, then DD's can be verified
Jose: the W3C will not define the extensive vocabulary -- this will be done by OMA etc
<Rotan> Observation, clustering can be external to the data (just like semweb annotation). Just an idea.
Dave: what is the difference between the Telefonica vision and the current requirements? Seems like the vision is beyond current requirements? Are there any gaps?
Jose: there may be gaps in provisioning, security and pay per view aspects of vision
Dave: need to have requirements updated for charter 2
Next presentation commences
"Strategies for tailoring web content for specific devices"
Disabled users have many problems with web access on mobile devices
Propose 2 solutions
1) Best practices
2) Device descriptions
<bmarks> q bmarks
List of best practices presented
DDR should help adapt content to mobile devices and assistive technologies
DDR should include accessibility/usability information
There are h/w and s/w aspects to this
Some assistive hardware and software solutions mentioned
Summary: it is important that the
DDR takes into account assistive technologies
... the needs of users with diabilities should be be considered
bmarks: 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
Jose: do you know the set of
capabilities that will be needed for disability information?
Will there be a module in vocabulary that will be devoted to
... 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
<nacho> [plus sign worked for me yesterday but not today... weird]
Rotan: if we imagine that DDR exists, how does an author know what the properties mean? How does the authoring tool make sense of this? How do you get human readable information out of the DDR?
Luca: you read the implemetation from a website
<Andrea> [it seems to me like Ronan is filtering the minutes]
<Andrea> sb, you work
Luca: documentation could be in XML, tools could import this
Rotan: should there be mechanism for adding international descriptions
Dave: let's walk before we run
bmarks: had a similar problem with UAProfs and semantics
<Andrea> jose, nuSOAP is not a full SOAP implementation. Unfortuntaly lacks some important things
bmarks: as long as you have a
semantic contract you allow the market place to layer on the
extra stuff later
... it would be a mistake to build this into the system -- it can be built on top
... these are business opportunities that may come later, not something for the w3c
Rotan: but what about an English description?
bmarks: It's more important to establish the machine readable semantic contract
Rotan: the meta data describes the data -- the meta meta data describes the data to a human, perhaps in an authoring tool
When you get to 100's of attributes, the problem becomes serious
Rotan: question about Telefonica
presentation -- exporting the data from a node -- what about
all the relationships in the data -- would you expect this data
to be exportable?
... If the data is a black box, the hierarchy information might not be useful to anybody else -- another node
... the XML format inherently has the hierarchy built into it
... would you expect the meta data relationships between the nodes to be exported?
Jose: thinks that the meta data should be exported
bmarks: There is easy way to
agree on flat node definition
... there was a similar issue with UAProf -- they agreed that each node was standalone
... This makes the data very big
... You can't know a priori how the data will be used
<Rotan> Nice phrases - "exportable single unit" and "atomic unit of export"
bmarks: So you have to go through the process of defining the atomic unit for export, otherwise it'll all fall apart
<Andrea> +1 to Bennett
bmarks: For machine readbility, the contract needs to travel with the node
<sb> +1 also
bmarks: UAProf wa criticized for
verbosity but not for technical issues -- this is not b/w
... Recommends that we don't try to manage the hierarchy
... This is a business opportunity
Luca: agrees with bmarks
... We should stick to the API .. ignore the underlying implementations
... Leave to each implementor how they want to model internally
Rotan: surface level export is enough]
Break for coffee
<asamim> ScribeNick: Andrea
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
Jose: do you think this satisfies all the needs?
Luca: WALL is for people who
don't know much about mobile or even nothing. They take WALL,
build this HTML-like pages and WALL takes care of
... if you are an operator or a big portal, you do it on your own
... or take WALL as a basis and extend
jose: how about pagination? CSS?
Luca: that's a feature that
should be added in the future
... on the other side, picking different CSS's, I thought about it, but never made it, because I think there are other ways to do it and not bind it to WALL and WURFL
... JSTL gives you all the tool you need, for example
Jose: maintaining a lot of if, then can be a pain
Luca: correct, but WALL already takes away a lot of the complexity
Rotan: ok, thank you Luca
... WALL is not so different from the DISelect features
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?
Stephane: if you want to work specifically on the API, then yes. If you want to consider an entire node, then you will need to talk the entire architecture
DaveS: I think it's important
that we agree that we are not going to build a new database
within the W3C
... there are already existing realities such as WURFL that could be a node of this federated system
... I think we need to clear up that we are not going to collect all the available data and make a new DB
Stephane: are you against the idea of working on the basic idea of working on the basic properties
DaveS: that's a different
question. The prototype and the data collection are not the
... 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
Stephane: 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
Yam: it could have been a Device Descriptions Framework
Stephane: Dan was there, what is your feeling
Dan: first I want to say that the
API should be a keyword in the re-charter
... it needs to be established and draw consensus around that
... and this is a separate issue if we should make a prototype, reference implementation or host the repository
... the API will still be a valuable thing
... and then the vocabulary
... do I still feel the need for the repository? Yes
... but it's still not clear to me who should build and run it
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
Stephane: we are not talking
about how you retrive data
... is this a topic we should work on?
nacho: I would like to comment
about the architecture...
... key to the success to this is to have a simple API
... that gives to people a vision of the node
... and the API should be a request that lets me retrive a single DD or a set of DD
... and leaves to me the implementation
... and leaves to me the implementation
... I could query another DDR in the background and then deal with the results
Rotan: I think Luca wanted to say
that the API should be the same when a client makes a request
to the DDR and the API the DDR's use to communicate to each
... 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
Jose: some information might get lost using UAProf because it is lacking some mechanisms to achive the full data we want to have
Bennett: I think this goes back
to the discussion we had this morning. There seems to be a big
... 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
<Rotan> ScribeNick: Rotan
(See summary doc that includes bullet points of items for inclusion in new charter)
Luca: could add metadata later in WURFL. We define api to retrieve info. Up to other reposositories to provide interfaces.
Quality and Trust costs money.
BM: There's the business op. Added value. Pay-for-trust...
Business ops come from creativity in implementations.
Luca: I see many "implementations" in the s/w industry. Many DBs implementing variations on SQL... etc.
Ambition - all freely given information should have some free DDR mechanism for getting this data.
BM: W3C should take proactive
stand on the rules associated with access to data.
... Pay for value-add is OK.
... Perhaps to enforce it, the published data would have to come out "copyleft". Any work/derived work must also be free.
... But don't want to force the issue of defining a value add.
... People typically derive from UAProf, not use it directly.
... Layer 1, UAProf should continue to be free.
... Layer 2, should also be free.
... Value add higher up is a commercial thing.
BM: If manufacturer incurs huge cost for no obvious benefit, then manufacturer pulls out.
<Andrea> I think all this and Bennett's will to chat with us shows how much Nokia is ahead of other manufacturers pretending this is not interesting for them
<Andrea> And this means developers and companies will develop contents and services for Nokia phones FIRST and maybe for other manufacturers
Luca: if DDR not funded then it
will never see the light.
... If we just keep it to API definition then I (WURFL) can implement it, and the commercial companies too.
<Andrea> Wouldn't it be great if Nokia not only exported their docs as PDF, but also as "DDR compliant format"?
<Andrea> Isn't it weird that SonyEricsson produces PDF's about their devices, but doesn't join this kind of activities?
MJ: Need to be careful not to enter into a copyleft situation where all derived info/processes must also be free
BM: Data available directly through DDR should be of the same level of freedom of access as the initial published data.
RH: Have to be careful not to extend freedom into value-add area or it will kill the commercial opportunities.
BM: Here representing Mom&Pop who will never be able to pay for such data.
Luca: which is why I think W3C could be asked to implement a node of the DDR to have this data.
RH: Steering Council anticipated
a possible cost associated with this work, such as hosting a
... Commercials invoved to grow the market.
Brainstorming ideas will be summarised in final bullet points of charter ideas.
JC: Hard to mandate a policy in W3C.
RH: Especially if Rec is open,
royalty free, means policy would have no teeth.
... Steering Council has also asked us to consider the role of the UA string.
AT: And need to consider separation of browser and device.
Luca: Perhaps use the entire set
of headers as (part of) the key.
... Any info from the request used as part of the recognition process.
Chris: That won't work in
practice. Headers changing over time, difficult to recognise
the device just on headers.
... They change even during a single session.
BM: Would accept that header
scanning is just a best-effort recognition. A hack. The only
one available today.
... This is not something that W3C should be pursuing.
... Those headers are not there to do what we want.
... Unlikely to get any new header installed. Years.
Luca: Up to implementer to decide what to do with the headers.
RH: Think we should a deterministic query.
BM: But need to consider at least
two dimensions. Device and browser.
... If I install a different browser, the characteristics will change.
... Requirement is to separate out device from UA definition.
... Come up with objective algorithmic way to identify a device.
... The hacks have to be resolved with a real W3C-supported approach to device recognition.
... The SC is asking us to solve the problem.
Luca: could be a new header?
BM: But there are a whole lot of reasons why a new header might not be the answer.
Yam: And also the dynamic properties.
<Zakim> Rotan, you wanted to suggest domain issue
Ed: Maybe we are too reliant on
the HTTP protocols. What about streaming clients etc?
... Need to be open to other technologies.
Luca: we could have other ids for
... we have UAProf header but not useful because not all devices have it, and dereference to useless data.
... Some manufacturers will never follow the technologies.
... Perhaps we should accept that hacking will continue in order to address this.
BM: So we get restricted because of sloppy manufacturers.
<Andrea> The bottom line, again, is that Nokia helps developers and companies, they will produce contents and service for Nokia. If the others don't, they will keep being number 2
BM: Have a clear policy (based in
time) of update and versioning.
... If you do ongoing update of Top N properties you need to interlock with OMA.
... For example, an update each January 1st.
... People need to know what to expect.
... This is a lesson we learned in OMA.
<mimasa> Rotan: please send your comments to email@example.com
<mimasa> ... thanks everyone for attending the Workshop
<mimasa> ... thanks T I+D for excellent host
<mimasa> Workshop adjourned
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/Telefonic/Telefonica/ Succeeded: s/scribenick ronan/ScribeNick: ronan2/ Succeeded: s/Presentation by Technosite/Topic: Presentation by Technosite/ Succeeded: s/Telefonica presenttation begins/Topic: Telefonica presenttation/ Succeeded: s/presenttation/presentation/ Succeeded: s/techogies/technologies/ Succeeded: s/liase/liaise/ Succeeded: s/1 also/+1 also/ Succeeded: s/algorythm/algorithm/ Succeeded: s/interchange protocol/interchange system/ Succeeded: s/some information/some mechanisms to achive the full data we want to have/ Succeeded: s/don't/doesn't/ Succeeded: s/are to/are too/ Found ScribeNick: ronan2 Found ScribeNick: ronan2 Found Scribe: ronan2 Inferring ScribeNick: ronan2 Found ScribeNick: ronan2 Found ScribeNick: ronan2 Found ScribeNick: ronan3 Found ScribeNick: Andrea Found ScribeNick: Rotan ScribeNicks: ronan2, ronan3, Andrea, Rotan WARNING: No "Present: ... " found! Possibly Present: AT Andrea BM Bennett DKA Dan Dave DaveS Ed Edward JC JuanJo Luca Luca_Passani MJ Martin2 MartinJ Nacho RCasero RH Rotan Stephane Summary Yam asamim bmarks cedric chris ddwg imarn2 inaki jcantera joined jose mimasa mimasa-sp1 mimasa-sp2 mimasa2 njal ronan ronan3 sb sb2 sboyera scribenick You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://www.w3.org/2005/MWI/DDWG/workshop2006/agenda Got date from IRC log name: 13 Jul 2006 Guessing minutes URL: http://www.w3.org/2006/07/13-ddwg-minutes.html People with action items:[End of scribe.perl diagnostic output]