See also: IRC log
<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 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,
Questions?
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.
<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.
Questions?
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.
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.
Questions:
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.
Agreed
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.
Agreed
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.
s/shouldln't/should'nt
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
<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).
... DIAL, XFORMS, CDF, REX
... 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 -
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.
Questions:
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
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.
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
xforms+xbl
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)
spreadsheet/server/...
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
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
<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.