W3C Workshop on Declarative Models of Distributed Web Applications, Day 2

6 Jun 2007


See also: IRC log


Charles_McCathieNevile, Marie-Claire_Forgue, Dave_Raggett, Steven_Pemberton, Kevin_Smith, Rotan_Hanrahan, Rhys_Lewis, Hideki_Hiura, Jose_Cantera, Bruce_Lucas, Charlie_Wiecha, Mikko_Honkala, Lasse_Pajunen, Koiti_Hasida, Stephane_Boyera, Sailesh_Sathish, Nacho_Marin, Petri_Vuorimaa, Fabio_Paternò, Kangchan_Lee, Joshue_O'Connor, Jari_Kleimola, Joerg_Heuer, Gorm_Eriksen, Joachim, Laier
Dave Raggett, Kevin Smith
Dave, Kevin, Rhys, Steven, steph




<Steven> Day 1

<Steven> --> http://www.w3.org/2007/06/05-dublin-minutes Day 1

<stef_dub> goooddd morning dublin

<Steven> Hi

<Steven> 21 in the room

<Dave> Scribe: Dave

Rotan's talk

Rotan presents without slides

<Steven> "I hate markup"

He starts by saying he hates and detests markup

Markup should be in the background

<Steven> Hate is a strong emotion to feel about a piece of technology :-)

Markup is a way of expressing an artistic concept.

<Charlie> some artists think deeply about the relationship of their technology to their art

Unfortunately after all these years we still expect authors to master markup. This is a failure of current authoring tools.

Word processors don't expose the details of how they store documents.

Rotan waxes lyrical about his experience as a teacher

His students quite reasonably expect the Web to hide the details of the data formats.

Rotan commends the Ubiweb to deliver on this expectation.

He explains that <em> was easy enough but the story lost its way when you explain <b> and <i>.

You should debate what it is you are trying to declare first, and avoid the temptation of sheltering under the comfort zone of the technology.

What is appropriate in the context of the current situation.

Rotan cites the case of inappropriate links/ads in emergency situations.

Please avoid repeating the mistakes of the past and instead focus on,making a success of the future,


Can you expand?

There needs to be a barrier between the authors and the details of the technologies.

The need to dive into markup is a failure.

Rhys: it is more a question of where you draw the line.

When people want to do really complicated things there is little alternative to exposing the details.

Rotan responds that whilst in the past we used to write directly in postscript, that is a thing of the past.

We should be addressing the needs of the vast majority of the population.

not the tiny geeky minority.

Comment: Adobe is doing this with their authoring frameworks for flash etc.

Rotan notes that the market battles are on flash, silverlight, etc. where the focus is on technologies rather than the needs of users.

We are wasting our energies wandering around battling the troglodytes of the caves and need to climb back out into the light.

(Dave thinks of movies like descent)

see http://www.imdb.com/title/tt0435625/

Rhys: to dynamically generate web pages today, involves a lot of complex scripting. Why is this still the case?

A declarative approach should make this easier to solve.

Rhys's presentation

<jo-siemens> Steven: I haven't found myself on the list (Joachim Laier)

<Krcsmith> Scribe: Kevin

Rhys fiddles with video settings etc.

(the projector hides the edges of the slides)

Rhys: we are moving from adapting static content to adapting applications.

He briefly explains what Volantis offers its customers in the way of hosting content adaptation services for big websites

The mobile web is largely used for delivering ring tones rather than conventional access to websites.

We have a database or around 4000 devices that we can adapt content for.

We want authors to create content in an abstract form suitable for adaptation.

Device independent markup is much better than device dependent markup when it comes to adaptation.

The challenge is to address adaptation of applications.

This means dealing with behaviour and not just static presentation.

He talks about calendar widgets in a travel site as an example.

Authors shouldn't need to care about the details for how such widgets are provided.

We need to make authoring simpler, and without requiring changes to browsers.

<Rotan> Hooray for good browsers. They let us do adaptation at a higher lever, rather than fixing the bugs.

This involves providing libraries of components.

These can encapsulate a bunch of server-side functions, e.g. Ajax/web services.

<Rotan> Web markup. Think "Angular Brackets". Dictionary offers these definitions of angular: lacking grace or smoothness; awkward; acting or moving awkwardly;

The components may expose parameters to the authoring environment.

<Steven> Rotan, don't think angular, think angelic

The components may be realized in complex ways with messy markup, css and scripting.

He shows a complex diagram where the client and server aspects are coupled via mutation events using REST.

Policies are used to control how device independent descriptions are realized for particular devices/browsers.

Perhaps we can use diagrams (e.g. UML state charts) for describing behaviour?

It seems to be practical to convert such diagrams to SCXML.

<Charlie> there's a plug-in for IBM Rational Software Architect that outputs SCXML from UML 2.0 state chart diagrams

<Charlie> it's been released on IBM Alphaworks

Devices are offering all kinds of capabilities such as cameras, GPS location, voice recording, that could in principle be exposed to web applications.

Rhys mentions the idea of an ebay app exporting data to the phone's calendar so that you get an alert that an auction is ending even if you are offline.

He mentions REX and DCCI as part of the solution.

Operators are looking for new ways to deliver services. One of these involves push mechanisms.

Who remembers Pointcast?

a few hands go up.

Pointcast failed as it involved excessive data transfer.

Buzzcast is a Volantis service that pushes content to phones.

He shows an emulation of a phone's screen in firefox.

The content is transferred overnight or when the phone is idle.

Users can then browser the content when they want.

The network traffic is optimized with lots of caching etc. to avoid overloading RSS sites

These applications use only a tiny fraction of the javascript capabilities of browsers.

This makes it easier to get it working on a wide range of devices. We have been shipping this for six months or so.

A knowledge of the author's intent makes it practical to work out how to degrade the user experience gracefully on a wide range of devices as appropriate.


Let's not restrict this to mobile.

Rhys agree's (with respect to work on standards)

Steven: are you telling me that ebay mobile uk is using XForms?

Rhys: partially yes. It is in the spirit but not quite there as yet.

Steven: we can compile XForms on the server to whatever the device supports. This will reduce the need for innovation on the browser.

Rhys: that is certainly true in the short term, but in the long term functionality can migrate to the browser when we have shown what ideas work and what don't.

Fabio: have you shown that UML can describe the entire application rather than just a single page?

Rhys: we would love to have help with task modeling etc.

Sailesh: there needs to be other levels of abstraction too.

Question about how the device caching of content works.

<Steven> http://en.wikipedia.org/wiki/Turtles_all_the_way_down

Rhys responds that this is something the OMA is working on with a publish/subscribe model.

This is named DCD (dynamic content delivery?). It builds on current technologies (SMS and HTTP) but future work may leverage SIP.

The delivery context can be used to take network and device speed etc. into account.

along with user preferences.

UI portability by Joerg Heuer

Practical experience with web based UI in devices/applications/systems can help us understand what is needed to enable application portability across devices.

Web UIs are being used for home entertainment, e.g. via browsers in set top boxes or newer television sets.

He points to http://www.oxyl.de as an indication of the kinds of UI involved

SVG and Flash will jazz up the UI. We are also integrating UPnP for device coordination.

Portability includes some means for adopting/extending the style/branding of portals.

Joerg asks who is using streaming in the living room currently?

One hand goes up.

There are significant usability problems

Joerg shows a photo of a car based UI using a screen integrated into the dashboard.

Good usability is achieved at the expense of flexibility.

<Steven> Rotan, get a chauffeur

<marie> :)

Joerg moves onto automation in health care.

Stability and timely behaviour is critical, but flexible configuration has become quite complex.

Argues that portability demands the ability to compose controls.

<Rotan> Manual composition of controls, interesting, but automated composition sounds much more exciting.

An interesting is how multiple controls interact.

Desirable aspects include separation of logic and presentation, scalable presentation, low computational complexity and mapping of events to navigation concepts (intent based events)

We need to study common use cases to identify the appropriate higher level models.


Rotan: where do you see the difficulties arising in automated composition of controls?

Joerg: it has to do with the reliability and trust, especially in automotive use cases. A manual approach works best for now.

Steven: software companies don't have a clue as to women's perspectives on applications.

Joerg: my wife is comfortable using the in car system, but not the streaming app in the living room.

Steven: devices are designed by geek men and this shows in their excess of features,

we break for coffee ....

<Rhys> Scribe: Rhys

Jose presents MyMobileWeb Project in Morfeo

Open source platform to simplify development of distributed web applications

Jose covers position of MyMobileWeb for the workshop

Developing apps for ubiquitous web is hard

JCF: XHTML is not a UI language. Scripting and server technologies filled the gap
... Developers keep demanding more. Led to Ajax toolkits, higher-level abstractions that are proprietary
... There are newer proposals, but not sufficient in themselves
... New standardisation efforts are required
... XHTML+XForms+Javascript doesn't have full set of UI components. No containers, layout abstractions, no expression language for objects (JSON)
... Don't separate bindings, relevancy, formatting, validations
... No standard APIs for XForms elements, model changes, creation of extensions
... No sufficient mechanisms for specifying hints for delivery to multiple delivery contexts
... DIAL also has important gaps. Eg differnent layout for differnent deilvery contexts
... Components rendered in different ways on different devices

<Rotan> Pagination of tables and menus can be a nightmare :(

JCF: menus that need pagination, tables and forms too.

But that misses the point that you define in device independent and the adaptation process does the modifications automatically

JCF: HTML 5 and Web Forms 2 has some improvements

<Rotan> Think Jose may be looking for something at an even higher level.

<Rotan> Though this doesn't build easily on what we have already, which is Chaals' point.

JCF: Inherits the issues from XHTML + tag soup reinvented means not ready for enterprise

My complaint was his claim that you cant base device independence on DIAL. There are existence proofs that you can

<Krcsmith> Also DIAL can adopt declarative markup via use of the XHTML 2 @role attribute

JCF: On HTML 5, the process and chances of agreement are low because of number of members

<Rotan> Agreed. Even our own XHTML-based solution is enough to demonstrate the model works.

JCF: Ajax toolkits not transparent to developer. Encourage imperative programming. Declarative styling inhibited. Accessibility reduced

<Rotan> Perhaps one could evolve towards an alternative along the lines Jose may be suggesting, but I'd not like to chuck the baby out with the bathwater.


JCF: Lots of javascript, performace issues, not easy to adapt for mobile
... Tag based abstractions JSF, XUL, XAML, Laszlo, MXML...
... Platform dependency, only implemented by one organisation, desktop orientation,
... Apache XAP reduces the need for javascript in Ajax applicaitons
... Hence MyMobileWeb, which includes a declarative language
... Low cost, modular, open-standards-based open source software platform aimed at semantic mobile web
... Set of abstractions of UI components, grid, menu, calendar etc.

These are different levels of abstraction. A grid is a concrete UI element, a calendar is abstract

JCF: Look and feel is controlled by CSS

<Rotan> We can do all those things (phone call, alternative object representations etc) with our XHTML-based solution, and so can others. The solutions continue to evolve.

JCF: Using their language they can do graceful degradation on different devices, pagination of tables,

<Krcsmith> Vodafone has a near-identical intent and instruction based XML model, which is then adapted for the delivery context.

<Steven> It is just not true that XForms has no calendar component

JCF: shows calendar widget rendered in different concrete UIs

<Rotan> Markup macros, custom tags, UI components... yes, these are all familiar, to all the adaptation companies.

Main problem is that the container language is not XHTML 2

<Rotan> (Think you were right the first time.)

JCF: Propose to standardise a new UI language, IDEAL. Shows a list of the functions that need to be standardized

<Rotan> Why not XSL instead of CSS?

JCF: Interoperable with XHTML, SCG, using CDF style composition.

<Charlie> why not xbl for custom controls, e.g. calendars?

JCF: Shows a diagram of the main components. Highly modular.

Doesn't seem to be much different from the roadmap for DIAL

<Krcsmith> Agreed. Proposal is that DIAL 2 include XBL

JCF: Could be other extensions, such as XBL
... How to develop IDEAL? Tried to do this via WAF. Found hostile environment. Browser vendors saw that as threat to WhatWG specs
... Also major players the area. Result is that the work has stopped, but they want to restart it.

<Rotan> DIAL-ng (inc XFORMS, XBL, XSL...), and maybe borrow some ideas from XUL/W3C Widgets, EL, etc.; Food for thought.

JCF: It is needed.


JCF: Within W3C: Could be new XHTML profile for UIs
... Muses on other ways to develop IDEAL via UWA, Backplane, joint taskforce

<Krcsmith> Agreed. There are some good points here, which should be brought into the DIAL roadmap (where they are not already there)

JCF: Could be done outside W3C, e.g. OpenAjaxAlliance
... Promotes IDEAL, and proposes that W3C shoud standardise it

<Rotan> Could DIAL use a declarative extension? Could we have a general-purpose XML language of declarations, for use in compound docs?

SP: Disagree with analysis of XForms because there are components for a number of the things you said weren't there

JCF: But that is not declarative

SP: Disagrees about how many times the declaration is made.

CW: Meta level question. Whenever we deal with a state of technology, there will always be a gap. Question is then what is the value we bring. Can decide to join or split
... The response could be to join the effort and help fix the issues, or you can throw everything else away and start again
... In Web 2.0 we have lots of UI frameworks 'balkanisation'. We need to move beyond the either or

<inserted> ScribeNick: Krcsmith

<scribe> Scribe: Kevin

Rhys: Similar to existing commercial problems.
... Layout IS missing from DIAL, but it shouldn't be there.
... We need a separate item to cover layout (outside of CSS).
... So it's not a DIAL/XFORMS etc. problem.
... There are numerous techniques for this, need to identify them.
... No pagination in DIAL, it shouldn't be there. No standard means.
... Shoudln't have to throw it all away. Some of Morfeo should fit well into DIAL.


scribe: There is more commonality than you may think between DIAL and what Jose presented.

Dave: Should be easier to convince people on incremental changes.

Rhys: Morfeo should be able to contribute a huge amount to W3C efforts in this area.
... as per Charlie's comments about working together.

<inserted> Scribe: Rhys

GP: Giles, works for DoCoMo, but representing PUCC

<chaals> [+1 to Rhys... and in fact it would be helpful to have some of this in the HTML WG too. WF2 provides, for example a date control (and likewise doesn't style it, although you can use ARIA, SVG/XBL, or a variety of techniques if you want) and HTML 5 from WHATWG has some extensions for UI components, but there are naturally gaps there too...]

GP: Been involved in MWI. Main guy behind PUCC is Kaz Kitagawa

<marie> (to omoimasu...)

GP: shows overview of presentation and discusses what PUCC does which includes Proof of Concept
... PUCC is non profit, R&D organisation focussed on peer to peer comms in home appliances, printers, fridges, cameras etc. etc.
... Not PC centric
... Take what already is there and build an overlay protocol to cross the boundaries between the existing technologies
... Shows combinations of devices that are being considered. Shows different communitites of devices that might be combined using this kind of lightweight overlay protocol
... Connect digital devices withouth a digital hub, such as a PC. Automatic service/device discovery and service execution using metadata
... No current solution to allow access to home appliances from other devices
... No device independent protocols for home appliances and digital devices, though there are lots of protocols that are used by some subset of devices
... Combine the individual webs, based on individual protocols, into a large Web with full connectivity
... PUCC is a Japanese legal entity, based in Tokyo
... Specs published in English, but not publicly available yet. Will change soon
... Shows list of member companies. Cross industry and academia partnerships. A number of companies are also in the W3C
... Lists the specifications under development. Common core protocol, common metadata framework, printing, home appliance, sensor network, streaming and security
... Working on outreach, by attending meetings and making specs public
... Several PoCs developed already. Mobile printing, mobile reference printing, mobile to TV streaming , remote control of home appliances
... Reference printing is print by reference. Chose from list actually hosted on a server.

<marie> demos avail. at http://www.pucc.jp/ceatec_dvd.html

<Rotan> (jitsu wa...)

GP: Shows diagram of the components in a number of the use cases just liste
... PUCC has defined device metadata. Allows device to describe the services that it has available
... together with its static data and state variables
... Devices can nest. e.g. printer/scanner/fax device
... Metadata is semantically rich and very high level. Very expressive and allows the service to be described in a rich manner, more so than Web Services
... Allows another device to interpret the data easily
... Air conditioner static - serial number, state variables- air direction and strength, services-setting direction, strength
... Shows more complex example with a TV with primitive devices consisting of the tuner device and the monitor device
... Static data, services and state variables apply to whole device and to the sub devices
... Shows a diagram of service discovery. It's dynamic. It uses the metadata to decide whether or not available devices can provide the requested service.
... Can request devices that are available, or only those that meet specific criteria
... Discovery uses broadcast if that is available on the network being used.
... Service invocation is normal request/response style interaction
... There is a publish/subscribe mechanism for events. Events are raised when particular state variables change value, for example.
... Recaps the PUCC specifications and the aims of integrating a variety of networks together.
... Think that there is the opportunity for collaboration

JCF: Is the metadata RDF?

GP: No, its an XML format, but there could be a possibility for alternate representations

Chaals: How do you know that what you discover is what you wanted?

GP: I have the discovery specs, but have not read them yet. It's part of the security model for the mechanism
... General principle is to reuse what is already there if possible.

FP: There are several protocols for communications between home appliances. How do you get it to be used

GP: It sits over the top, we define bindings

RH: Consider an airconditioner in the ceiling, curtains that can be opened and closed, and underfloor heating.
... I say 'turn on the cooling'. That is imperative. Better to say 'I want the temperature to be X degrees'. Goal directed, and let the mechanism figure out the way to achieve it.

GP: Agree that is a good long term goal, and we need to start on the way.

RH: Opportunity to combine these into a single, goal directed application

DR: Do you envisage a richer, state-based view of the metadata in the device.

GP: Don't know that it's in there already, but when I talk about a rich model, that's the kind of thing I think needs to be there.

DR: The complementary idea is that of asserting constraints on the process.

GP: No, there is nothing like that at the moment.
... Intention is to try and collaborate on this with W3C. Lots of potential for outreach back to Japanese companies who no longer participate. Also chance for PUCC to get a more international outlook.

DR: If devices are older, they may not have the most up to date metadata. The ability to manipulate that data separately improves flexibility
... Adjourns the meeting for lunch

The Web everywhere (Charles)

<inserted> ScribeNick: Krcsmith

chaals: Want to talk about what Opera is and does
... There is one Web, lots of uses.
... Trying to make a mobile Web doesn't work.
... Has been tried before.
... Since the Web is not going to collapse, it will go in one way. Should be standards based.
... (ref: Opera users slide)
... 40m handsets with Opera, 60 handsets. 10m Mini users.
... (explains range of device capabilities). Opera Mini for low-end phones.
... Also various other device types (Wii, Airplane seats). One laptop per child project involvement.
... There are other browsers. Joost and MyTube turning PCs into TVs, STBs doing opposite.
... iPhone will bring Web to phones :)
... Kiosks, printers etc. running Web browsers. Diversity increasing. Moore's law means cheap phones more powerful than earlier PCs.
... The cpability gap is increasing.
... The browser IS the platform. That's what the Web apps end up in.
... Cool services based on existing technologies. Innovative websites built on use of standards.
...ref: Steven's slide on processing power. Wii does not give a powerful platform to build a browser on.
... People's expectations have risen (for wider technology feature set).
... Either support backward compatibility or ignore it and drive ahead (not recommended).
... Companies who admit they were wrong or throw out everything they have worked with.
... So legacy devices/tools persist. They do not change fast. So the content will not change fast.
... HAving a simple migration path very important.
... Ubiquity; e.g. trying to fill a form with a Wii remote.
... Chaal's blog site. People can blog from a Wii.

<Rhys> It's called outsourcing isn't it?
...ref: Also, who controls yor data? Mail, spreadsheets, documents? Which company would trust putting sensitive documents on Web?

<nacho> [I think chaals said the blog entry was made from opera mini.... even much greater than from a Wii, IMHO]
...ref: Opportunities; being able to hook up different browsers and maintain states.
... Opera has Javascript hooks to facilitate this.
... Huge market for location services, e.g. tracking your children.
... Family browsing in living room.
... Disagree that WHATWG prevents declaration. Rather the team recognise the importance of innovating with scripting. It takes time (ref: XFORMS) to get declarative techniques available.
... Usage is exploding. Standards democratise development. Things are more, or less, declarative. The goal is good, it means more people can do it.
... Should we have new Web standards? There is work already being done. HTML needs clean up, fixing where bad, adding where needed.
... DOM model to know how a page will be parsed.
... CSS, ECMAScript 4. Essential that people can write scripts. Have made sure of backward compatibility, and optimises. Hard work but useful.
... Allows you to write for new use cases and deploy them.
... For adaptation, the CSS3 media queries. (Although ideally there would be no markup).
... Also device description, various buzzwords. SVG needs some clean up.
... Canvas is much lighter weight than SVG (no DOM building or manipulation needed).
... How much more do we want? Need to identify what we need, and what we have already done?
... Important to clean up what we've got so we can reuse it for new cases.
... e.g. people have need to show dates. Many options, how should we proceed? Big risk is a new idea that changes the world but forgets the world before.

Question from JFC: IF innovation is disruptive, human knowledge will not advance?

chaals: Standardisation should not be disruptive. It should recognise that leveraging existing standards has benefit.

JFC: Danger of no innovation

chaals: Need to move to survive.

Steven: Have you read 'the innovators dilemma'? Documents failed companies that have moved too slow. Disruptive stuff happens overnight.

chaals: Not saying we shouldn't innovate. W3C is SDO, not R&D.
... Good standards work by seeing which ideas worked, without changing the way things work.

Rhys: Need to be careful what we choose to standardize. Standards may appear in next charter. What is mature enough now for us to innovate on.
... How to get anything new into the Web? Theer is a huge amount of stuff in use already, so innovation should fit into this.
... Adaptation does not break anything.

chaals: We want it to spread down to low-end devices with browsers.
... XHTML 1 work as example. Was built upon what came before.
... Users will drive the uptake of the standards.

Steven: Same argument for CSS, 'can be done with scripting'?

chaals: Look at the usage. If there is demand we will innovate accordingly. Hard to call standards widely-deployed unless they are.

Steven: So we should develop standards and Opera will implement them?

chaals: Opera can bring innovation to W3C (widgets).

- end of chaals' talk -

The importance of User Testing (Josh O'Connor)

josh: Interesting to hear about tools for authors
... implicit and important that they are easy to learn.
... Within UWA context, security is important. Usability considerations can help that.
... Believe real need for more user testing.
... NCBI has dedicated testing facility.
... (shows HCI introduction slide: Human-computer interaction)
... What's wrong with HCI (ambiguous definition)
... Responsibility to ensure applications usable.
... (recommends 'The design of everyday things')

<Rotan> http://www.amazon.com/Emotional-Design-Love-Everyday-Things/dp/0465051359

josh: What is user testing? Observation of success rate of task completion, and subsequent improvements.
... As regards people with access/usage difficulties, NCBI provides user testing process.
... Screen reader allows voice interaction with computers.
... In fact blind Web developers as well.

<Steven> Read this one first (before 'Emotional design'): http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107/ref=sr_1_1/105-6282292-3862844?ie=UTF8&s=books&qid=1181136499&sr=1-1

josh: Switches are single buttons. In combination with the Grid (scanning application, highlights a grid square every 3 seconds). The Switch can interact with the Grid.
... Advantages of user testing. Reveals issues that would be difficult to predict.

<Steven> http://en.wikipedia.org/wiki/Switch_Access

josh: Well-written Semantic content will assist accessibility.
... Identifying structures, as opposed to styles, is important.
... As assessment methodology: helps fine tune UI. Very flexible.
... Greater need for testing to help developers, and also let SDOs know the impact of their decisions.
... Leads to improved consistency and quality for the users.
... Developers not aware of all their end users and so assume a model user.
... People have different level of use of a given assistive technology. So difficult to make assumptions about end users and to group them.
...Security: Semantic defficiency to describe UI. XHTML 2/HTML 5 will help.
... Currently look for padlock/pop-up alert for secure websites. Need to ensure blind people can be informed accordingly.
... Suggest user testing as part of corporate and government responsibilty.


Steven: Google is also 'blind' so will benefit through that channel too.
... Usability needs more visibility within W3C.

<Steven> Also good: http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pd_bbs_sr_1/105-6282292-3862844?ie=UTF8&s=books&qid=1181137193&sr=8-1

josh: NCBI keen to get involved

Krcsmith: Usable tool for authoring?

josh: yes, there are blind web developers, they have favoured tools (psp pad?)

Steven: Forrester research studied 8000+ users as to why they used one site over another.
... Included dozens of variables. The four key ones were: 1 content 2 usability 3 speed 4 freshness.
... Companies do not treat usability seriously.

-- end of Joshue's talk--

<Steven> Those 4 all scored more than 50%; number 5 scored 14%

[onto discussion period]


<Steven> Scribe: Steven

List of topics

Tools to hide tech

Capturing intent

Aggregating and aligning related techs

Content adaptation and indexing

[Votes taken on what to discuss]

Goals vs constraints

End-to-end models

Implementation strategies

Reusing what works

Standardising on what, exactly

Standardise on what exactly?

Kevin: One approach is APIs

Lasse: Do we want to standardise APIs (things between components) or the componenets themselves?

Steven: THe reason for standards on documents is interoperability. For instance, blogs: once you choose one, you can't move to another wihtout losing content

Rotan: Do we have a concrete definition of intent?
... that's where we need to start

Lasse: If you start top down, you need to be very generic, to be future-proof
... solvng real world problems in a lower level will give results

Rotan: That sounds like organising a banquet where everyone brings their own ingredients, without agreeing on who brings what

Jose: The three axes are application model, UI description (View), and controller

Rhys: Rather than top-down or bottom-up, may be middle-out is the right way
... state machines are a good technology

Kevin: What should not be standardised?

Rotan: Mechanisms. We must not get locked into 2007

Rhys: There should be APIs for the 20% who can't use the componentry

Chaals: Security models should not be simply laid down as a series of musts. On the other hand, a security model should be suggested, and explained - so implementors have an idea of the risks and common approaches, and authors understand what things are not normally going to be available, and why. Since security can change, and since there are often use cases for opening it in particular circumstances, simply insisting on some blanket restriction or permission is not generally a good idea.

Charlie: We should support the use cases we have, rather than what could be done

<Charlie> and an important use case is related to composability of web apps

Koiti: Three things 1) APIs 2) persistive data 3) bidirectional stylesheets

Charlie: [scribe misses]

Dave: This question is hard to answer in the abstract

<Charlie> standardizing the APIs might still imply getting some "base" or "shared" APIs right to allow for easier interoperability and "snappability"

Bruce: Supporting what Charlie said, there are things you can't do with APIs
... but we need to be clear with what we mean by API

Giles: Agree. Is it just a list of functions? I don't think so

Dave: We need some motivating use cases

Charlie: To be a servlet you have to implement a servlet API

Dave: A printer wouldn't be much good if it didn't print. An API is not enough

Rotan: It would be useful to do use cases, but be careful, because often they take over
... and you end up only discussing the first one

Kevin: How about "Capturing the intent of the user"?

Dave: Few people use the preferences on their browser

Rotan: That's explicit intent
... but there is also implicit intent
... so even if they don't explicitly show intent, you might be able to infer it

Rhys: There are two aspects
... static, making sure the site is properly designed
... but there is also dynamic, "why is the user here"

Rotan: If you can identify goals, than achieving it is the ultimate intent

Josh: Intent can change during interaction

Rhys: I have used systems that tried to guess intent
... but when they fail, it is completely unexpected
... what they actually do

<mikko_honkala> http://twittervision.com/maps/show_3d

Lasse: Twittervision
... shows location of people sending comments

<mikko_honkala> or the boring 2d view: http://twittervision.com/

<Rhys> KS: inferred intention, like amazon history. Forcing of intention on user by author

<Rhys> KS: In vodafone, there will be associations between content types based on associations in real world

Dave: Search, where you try to guess what they want to search for

Rotan: That just encourages people to be lazy

Dave: But is is an example of letting the computer taking work off your shoulders

\Kevin": Aggregating and aligning related technologies

scribe: how to do we get organisations work together

Jose: We should recognise gaps in standards, and decide how to fill them

<Schnitz> hello

<Rotan> Gap analysis, and gap filling. Like Web dentistry.

Jose: And we need to align with open source groups too

Charlie: We need a hippocratic oath of doing no harm
... how to work in an incremental fashion

Rhys: Open source just happens, and we should let it

Jose: The incremental issue is market driven
... my concern is that things are done in different working groups with different timings

<Rotan> Jose indicates the reality that standardization is a lot slower than the Open Source community, the market, the real world etc.

Rhys: Timing is everything

<CharlieW> one can still work in the open source community while consuming what has been already done in the standards

Rhys: but the good thing is that a W3C charter is a stake in the ground, a signpost for where people are trying to go

<Rotan> A W3C charter is a declaration of intent. Doh...

<Rhys> RL: Good thing about W3C process is that early drafts provide signposts to the community about which direction is being followed

Dave: How about "end-to-end models"

RHys": How about a break?

<mikko_honkala> break +1

<Schnitz> +1

<Schnitz> ;-)

<Schnitz> Steven, I have been attending for 5 minutes remotely, time for break!

<Schnitz> ;-)

<Rhys> Also, since we're talking about declarative approaches, we are shielded from advances in Ajax or other imperative techniques and the heritage of existing implementations

<Fabio> TEST

<chaals> bye folks...

<cfit> test

<stef_dub> success

<cfit> With any user interface/application it is important to ensure that it is accessible. For example screen reader users may have problems accessing AJAX type applications where continuous data streams are constantly being updated. Often the widgets or AJAX type parts of the application have to rely at best on the limited semantics available to them via HTML/XHTML to describe the purpose of the widget. This information is often revealed to the user via the OSM as scr

<stef_dub> scribenick:stef_dub

<scribe> scribe:steph

board are dancing in front of the room

Dave: use cases gathering

<cfit> I hadn't finished that one! Oh well.

use cases

Lasse: people sending messages to the world

twitter service

<mikko_honkala> http://twittervision.com/

closer to the user experience we are expecting

to produce ths service, evreything is here

but the implementation not adaptable for eg accessibility

should be more adaptable

standardize so that it will be adaptable to mobile/tv/...

what to do ?

<cfit> Someimes more complex layers/levels are often not needed for blind users. Fancy interactive maps are reduntant when a structured HTML file with some well written content would suffice. I guess the one size fits all approach often does not work.

3 areas: model the user interaction, apps model, UI rescaling

no way to do it easily

all these parts should be eaisly describable to make it adaptable

<cfit> Textual descriptions in some kind of semantic wrapper may do it.

Charles: good example

composition is cool through google map api

but the popup are just called individually by a method

needs more transparency

no way to capture eg the event on the model

loose coupling between map and apps

rhys: describing something about the behaviour

Dave: xform and controller should help

<cfit> Behaviour/Presentation/Semantic info should be separate?

Charles: should work through a feed of events the data model should listen

or subscribed to

Kevin: accessiblity is a problem, how to improve it here ?

<cfit> I am not sure what the purpose of this map is.

Steven: saw such capabilities with google map and foaf


Charlie: what's good for accessibility, good for other also

separation of the model would be great here

<lassepaj> http://flickrvision.com/

sailesh: example of what rhys presented this morning,

geo-blogger apps

<cfit> I get it now

<cfit> Thanks gorme

Kevin: modeling user interest may be very interesting

???: google map is a service by itself

physically consistent set of maps

conbined with constraint

Sailesh: my input to the workshop: i've nothing to show

want to speak about what apps should be

in living-room watching tv, receive a mesg saying that a new picture was uploaded by a friend somewhere

and the apps would ask if i want to have the photo displayed on the TV

<nacho> bye everyone

very simple scenario

how to enable such a scenario ?

basic requirement: you need a proper delivery context vocabulary about appliances, features on them,...

and then proper access to the Delivery context

then you need something in hte background to communicate with your tv : Pucc/upnp/...

good to have flickr or such service opening their api for such an application

proper ontolog, proper access tothe DC proper networking protocol

Charlie: share the complexity in different layers

client interaction/JSP flow/user task flow/business process flow

2nd driver: evolution is important

apps should evolve

over time

more flexibility among layers to facilitate evolution

<cfit> what about dormant properties that are context activated?

things may evolve from client side, ui component, to server

the notion of client ui evolve also

from eg desktop to mobile, you may cut the ui in multiple parts

Dave: lots of talks about spreadsheet 2.0

shoudl be able to define very easily a form in a browser and twick the properties

then descrbe the data flow (where data are stored)


access control on top

to define security

<Rotan> XHTML Role - http://www.w3.org/TR/xhtml-role/

Rotan: role attribute model

visited that in 2004 in dublin

outcome of the workshop in dublin 2004 (metadata for content adaptation)

simple things, like navigation,main,secondary,...

role of pieces of content in a page

<Dave> Dave adds that the editor for the form would save it in a way that captures the intent and which enables the form to be adapted for delivery on a wide range of devices.

without that silly adaptation engine could remove most important part and keep advert

with, easy task

same for apps

what are the major part of the apps that should be kept, and those who can be trashed in adaptation

uwa should consider this use case

Rhys: reason of role module in xhtml

because of lack information

hope i've with our new markup we would have mechanism to attache semantic

semantic enrichment

Charlie: you can do this today, anotating elements

<CharlieW> c/Bruce/Bruce

good idea for behaviour in apps space\you need now to be able to hook that not existing for now

<BruceW> * i don't think i got it

<CharlieW> *hopefully that's the right number of changes

Rhys: design should be semantically based

component semanticaly labelled

Gilles: disruptive example : mobile ajax and the battery use and power

ajax is the buzz word, but not work on mobile phone

should not require this cpu power

it is inefficient

particularly on low devices

useful to have a way to program what are important bits and what are those would could be dropped in constrained environment

Rhys: good test case for mobile ajax implementation

what does mean "it works" is questionnable depending on the evalutaiotn criteria

Dave: rich web apps are hard to adapt

Steven: xforms+google map: process intensive : not a problem

just get the coordinate got from the functionnal part and than displayed by a widget which is displaying the map

Jo: lack of semantic to describe things like a map is a problem

what should w3c do next ?

Rhys: full steam ahead

Steven: a strong area of work : late binding of user interface to functionnal core

a la XBL

GE: impact on the speed of the apps

Steven: joost doing it, that's true that they are doing special things to speed things, but that does not imvalidate the concept

Lasse: afraid too much WG at w3c, problem of coordination

loosing time

not a new WG

should be incorporated in existing activities around that topics

Rhys: WebAPI and WAF : they have no bandwidth and not focusing on what we are talking about here

nothing browser related.

usually i would agree, but here they have no desire to work on that

GE: the problem is implementation of XBL

Rhys: we should drive work based on adaptation

we would not infringe any WG work

some of things we talk are quite advanced by others and we should let that go,

but other things we should work on that

beginning of consensus on using states, semantic enrichment,...

i recommend to work on page flow

Charlie: let's define ubiquitous

what this si about

lots of fragment around web technologies we want to bring together

we should focus on composition

and evolution of apps

Kangchang: the termnilogy is ambigous

what do we want to achieve ? like deivce coordination

<cfit> is there a need for a semantic gap analysis, or is that for other WG's?

identify the technology is essential

we should identify what we should not do

and let that to other WG or other stand. org.

Bruce: interesting connections between the different points written down

???: composition and flexibility is important

API and service interface are keys

Dave: rich service description ?

???: summary : declarative service interface

Lasse: problem is current implementation are problematic. to imporve the situation by supporting client development

so that they would support better standards

better test suites to help client developper

so that more and more clients would be able to render in interoperable maner content

<markbirbeck> 2-penneth worth: Problem is that the W3C spec architecture is not conducive to what we need, at the moment. (Broken record, I know.) We need lots of small, light-weight specs, some of which define 'the thing itself' and some of which define how to combine things. For example, XBL is nice, but not a big deal--what is far more important is the method of specifying the decorators.

Rhys: +1 we may want to move function to clients

but not only bugs are problems

different form factors

<markbirbeck> So defining the bindings seems to me to be more important than defining what is bound to.

which would always need adaptation

no value for browser maker to integrate new things now, so perhaps later, but for now we need to convince them on the importance of the new things

Mikko; lots of things for now for UI, i would prevent any work on UI descriptioin

Dave: feedback could be not only for UWA but for others

if there are gaps we would see which WG is most appropriate

Rhys: no plan to work on xhtml/xforms

we would build on top on the standard not modifying the existing standard

Dave: so identifying gaps should be a task of the wg

in ui description technologies

Jo: feel nervous about ubiquitous and relatioin with accessisbility

Dave: the idea on focusing on declarative qpproach for authoring is a step towards accessibility

a better support of accessisbility at the end

Rhys: WCAG has a role to ensure that we are doing the right things

adaptating for mobile phone is not that far for adapting for visually impaired people

Charlie: big point on overlap between WG

this my feedback to take care of this point

coordination are not really working well

(coord. groups)

Dave: missing things for that to happen ?

Charlie: don't know. it is just that's a problem

most of technical recommendations we are making here are cross-cutting boundaries of groups

GE: security is also a big point

Giles: PUCC recommendation: work with PUCC on rich service metadata

Lasse: my experience with CDF :

xhtml/svg can work together.

we learnt that it is better to do anything (no rec) but try to influence XHMTL and SVG to twick their recommendation

here the same, cautious to start new spec, but try to have old spec updated

<Rotan> "One spec to rule them all and in the app to bind them."

Jose: your point is theoritical

but if you can influence html group, let me know how, without waiting for 6 years

Charlie: don't agree with Jose

xhtml wg is responsive

MCF: more uses case ?

Steven: each web applicatoin is a use case

Dave: what are business driver is important to identify

Charlie Demo (and end of minuting !)

<Rotan> This is the end of the "Web page" as we know it. From now on we are dealing with fragments composed from engines that are trying to represent state via the browser :)

<Steven> Dinner?

<Steven> +1

<cfit> Thanks all, Josh signing off.

[End of minutes]