See also: IRC log
<Gottfried> scribe: Gottfried
Jason White: Some questions require more research than just spec reviews. It was decided to establish a tf for this.
Jason: A work statement of RQTF is available: https://www.w3.org/WAI/APA/task-forces/research-questions/work-statement
... We also have a work plan - https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Work_Plan
... But we have an insufficient number of people - trying to recruit currently.
RQTF page: https://www.w3.org/WAI/APA/task-forces/research-questions/
Jason: Constant dialog between RQTF and APA envisioned wrt the results of the work plan.
... First topic - Accessible authentication. https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Work_Plan#Topic_1:_Accessibility_Implications_of_New_Means_of_Authenticating_Identity_on_the_Web
... Important question: New requirements on user agents and authors needed to be included in the a11y guidelines?
... CAPTCHA authentication. https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Work_Plan#Topic_3:_CAPTCHA
... PF developed a W3C note formerly. https://www.w3.org/TR/turingtest/ (Nov.
2005)
... RQTF has been exploring this issue separated from authentication.
... Personalization on the Web. https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Work_Plan#Topic_2:_Supporting_the_Personalization_of_Web_Applications_-_Requirements
... In W3C this topic was driven by the IndieUI wg. https://www.w3.org/WAI/IndieUI/
... This involved media queries and custom APIs.
... IndieUI wg closed without a W3C Recommendations. But the former members of this group are still concerned with this topic.
... IMS Global Learning Consortium has a relevant standard here.
... We hope that we can tie into work that is happening outside W3C.
... Idea is to develop some guidelines for the conduct of accessibility-aware
research.
... Plan is to start work by asynchronous communication. And then start regular meetings once enough participation is available.
Rich: What is happening with personalization and authentication?
Jason: Personal needs and preferences profile group in IMS run by Madeleine Rothberg.
... Educational assessments according the QTI framework of IMS.
... No integration yet with other work such as W3C.
... We want to achieve some level of coordination here.
Rich: All approaches are missing out on the user's data, i.e. lifecycle of the day.
... To address cognitive disabilities, you need to know what the user did before (e.g. don't buy things that you have already bought)
... It must be more dynamic and more peer-to-peer.
... Preferences should be in a block-chain, not in the cloud. No central authority.
... The whole way we have been doing this is fundamentally flawed.
Jason: COGA tf has an extensive table of user requirements. One column discusses parameters that would need to be personalized.
... These are very distinct needs. How to develop user interfaces that can adapt appropriately?
Rich: There is a need for a standard. We can use the vocabularies that have been defined in GPII.
Gottfried: ISO/IEC 24751-1 defines a registry approach for preference terms. ISO/IEC 24752-8 defines a format and API for user preferences.
Jason: If you want to simplify things you might want to do this on the basis of what the user did before.
Rich: Companies have the history of the user. But there will be a push for the user to have their own history version stored in a block-chain.
... Block chain is a buzzword now. But we need to define in detail what this means.
... We cannot get cog and ageing without personalization.
Jason: We need to position the W3C standards in this regard.
... W3C has some block-chain related work - workshop.https://www.w3.org/2016/04/blockchain-workshop/
Rich: This would also apply to education space, right?
Jason: Information on tasks and exams etc. could be valuable.
... Adaptive tutoring systems and adaptive examination systems.
Rich: Peer-to-peer approach - you only give away what you want to give away.
Jason: IndieUI wg faced the issue of security models. Users need to be in a position that they can decide which information they want to give away.
... Security and permissions needs to be in place.
Matthew: Facebook is focusing on internal information.
Gottfried: Previous work on PPP could fit in here.
Rich: ARIA wg is supposed to do personalization, also authentication, in addition to vocabularies.
Jason: I will cooperate with Rich on the work of the ARIA tf.
... Let's keep the recruiting process moving for the RQTF.
Janina: How do we interface a11y through APIs? This is commonly done by W3C wgs.
... Vibration API got feedback from us - will get in. Security wg had a similar requirement.
... How do we cover accessibility in the APIs?
Matthew: Spec review process can deal with this.
... I want to work on concrete things.
<David_MacDonald_> monitoring from WCAG meetings down the hall...
Jason: Next major revision of a11y guidelines could be a single spec combining WCAG, ATAG and UAAG.
... Interplay between the spec, API and guidance of implementation.
Gottfried: Personalization needs to be taken care of more concretely. E.g. provide modules for APIs to take care of accessibility.
Joanie: Generic questions that API providers care about. Interaction with AT - information to expose.
Matthew: Systems engineer get to the point where they think they have some understanding of AT. Then they make these decisions.
Janina: But also the other way.
Joanie: I would like to get systems engineer think about the a11y issues themselves rather than just going to APA.
Janina: On Wed we need this as a requirement, not a request, about what the API does - not just technical content. This is needed for identifying the accessibility requirements, but also for other engineers looking at this and wanting to use it.
Matthew: If you don't know anything about a11y - where are our read-up docs? It is so hard to write things so that they are understood outside of your domain.
Janina: WTAG = Web Technology Accessibility Guidelines.
Michael: We will need to sync up with WCAG on personalization.
Rich: People need to look at this in an entirely new way.
Janina: This is not only about technology.
Jason: That is the purpose by the RQTF by engaging people who would otherwise not be in the discussion.
Michael: Do we need another document on APIs? We don't even know if this is a good way for a11y.
Janina: Without an explanation what the API does is absolutely needed.
Jason: Developing an API tends to shift the responsibility around. Anybody who develops against an API tends to need to implement a UI, but there is no guidance.
Michael: This is a big whole right now.
<jessebeach> An "accessibility impact statement" is a good way forward
Janina: Every new charter in W3C should include that they are obliged to talk to APA about an accessibility provision.
Jason: Anybody who wishes to join the RQTF please talk to me.
<LJWatson> Meeting minutes for WebPlat WG (where you'll find the Web Comps + ARIA discussion) https://www.w3.org/2016/09/19-webapps-minutes.html
See the minutes of the Web Platform WG for this topic.
<MichaelC> Extended Description Matrix: http://www.w3.org/2015/08/extended-description-analysis
<MichaelC> scribe: MichaelC
js: above matrix address various things descriptions need to do
aria-details addresses many of those
but still need to support users who don´t use AT
gk: beyond that, other people also want to get at these descriptions according to publishers
use case, physics diagram with physicist-written description, many wanted that rich content
s/topic: Extended/Expanded Descriptions//
jgw: there is HTML details
web components could implement elements
aria-details to tell AT where the description is
aren´t the requirements now satisfied among all that?
perhaps need for a standard visual cue
<janina> ?q?
though that has questions about standardizing UI
gk: not disrupting presentation important to publishers
want an unobtrusive cue
<mhakkinen> +q
jf: is the cue author-provided or chrome-provided?
how do we address discoverability?
js: can it be a plugin, is that sufficient?
lw: don´t see use cases evolving, but we need implementers involved in the discussion
mh: ETS authors long descriptions, for test takers with learning disabilities
lacking something in HTML, we wrap images in <figure> and put description in a <div>
we also do tactile descriptions
no role on the description div
did an implementation using web components
provide an unobtrusive overlay as a style option
but this is all because the browser doesn´t do what we need
want programmatic access
<mhakkinen> DIAGRAMMAR - http://diagramcenter.org/standards-and-practices/content-model.html
as: icon stylable by CSS
allows adaptation to content for various designs
<mhakkinen> Prototype Web Component for DIAGRAMMAR - https://github.com/mhakkinen/dg-content
note there is no single extended description, e.g., a photo may have one of the subject and another of the camera settings
how does AT know which one to use?
jgw: hear that the visual cue needs to be readily recognizable, by people with various backgrounds
and that it shoud be unobtrusive
are those requirements compatible?
to what extent should it be stylable while remaining recognizable?
<Zakim> janina, you wanted to say it's more than just longdesc in new clothing
js let´s not say this is longdesc all over again
longdesc, though a spec and implemented, doesn´t meet all the requirements in the matrix
aria-details supports more of them
agree discussing without implementers insufficient
we need them to understand these use cases apply to more than just digital publishing
<joanie> scribe: joanie
JF: Jason talked about being unobtrusive.
... The first thing that jumped to my mind was some sort of watermark.
JH: It's style-able.
JF: What does that mean for people with low vision?
... In the WCAG meting this morning, we were talking about personalization. There seems to be some commonality here.
... And it needs to be customizable per user.
GK: Wouldn't the AT take care of that?
JF: It's not just for AT users.
... Discoverability for screen readers is not a problem.
... The problem is for sighted users who are not using a screen reader, but have other needs.
<mhakkinen> +q
JF: It seems to me that the description is being embeded in the same document.
... And the piece that seems to be slipping through the cracks is external documents.
Romain: Regarding the visual cue and could it be part of the chrome, I don't think having something in the browser chrome is going to work.
... These sorts of things do not have a good record for being implemented by user agents.
... It should be doable to have it handled by CSS.
... At the end of the day, it depends on the design of the site.
... And if it's done correctly, the end user should be able to recognize the presence of the description.
SF: I'm trying to understand the scope.
... We already have aria-details. And by default, it is not going to have a corresponding visual indication.
... What we need to say is, "Here's the definition of a user interface control."
... We need to incubate this and also get the browser vendors to participate in that discussion.
... But a better strategy would be to decide what we want this visual indicator to look like, and get it to enhance the user experience.
... The hard part is getting the user interface control implemented in the browsers.
... That's why people are looking at how to use existing functionality to accomplish what we want and need.
... Mandating what it looks like is a non-starter.
... What goes into a spec is the functionality; not the appearance.
... You can make a suggestion regarding appearance, but the way browsers implement it is the way they implement it.
... It can
be unobtrusive, like the details "twisty".
... But it needs to be sufficiently perceivable and clearly interactive.
MH: I want to follow up on what John said.
<MichaelC_> scribe: MichaelC_
mh: need things not to leak out of test
our design is to have a description contained in a block and point to external source
in a web component, we would need to override default affordance with specific user´s need
so we want to know the UI mechanism but don´t mandate the style
<Zakim> MichaelC, you wanted to say -1 to specing UI, let s just spec a good hook
mc: specifying UI will cause more problems than it solves
need a hook and a recommendation, but not a spec
js: back to plugin sufficient?
sf: with details, something can be activated via fragment link etc.
jf: or could point outside
khs: @@
<MichaelC> scribe: MichaelC
jgw: scripts and style sheets can pick up aria-details
and faster than we´d get a custom thing in HTML
allows author styling
is there a new technical feature required? seems to me no
<Zakim> janina, you wanted to point out that aria-details over details/summary was a compromise with browsers -- aria-describedat actually fit the reqs better
js: agree a mainstream argument will help in implementer discussion
like the discussion we had with web platform before lunch
we´re already compromising
aria-describedat arguably met the requirements better, but one implementer didn´t support
we´re trying to find something comfortable for community as a whole
gk: objection was potential to go off page
aria-details stays on page
sf: put aria-details on link?
could mean description of the link target
all the interaction exists
js: aria-details is for disambiguation
sf: discovery is an author technique
ac r
rs: publishers wanted visual indicator but not changing document design or script
therefore want css
agree the mechanisms exist
need something to activate through UI to decide whether to show the indicator
via media query or something else
gk: that helps MathML discussion
could expore the media query approach
old systems wouldn´t support, but that´s ok
rs: need no script, the css can decide whether it applies
need to figure out how to set that media query value
could be done via plugin
gk: for books in browsers, something we´re interested in
as: @@ based on browser
jd: re multiple types of details
aria-details can only reference one element
gk: yeah, having multiple types is important to diagrammer work
allow user to pick which one
rs: media query for that too
mck: how about make aria-details reference multiple elements
jgw: display or hide based on user pref, media queries seems the obvious choice
like some other stuff we´ve been doing
how about extensible vocabulary of media queries
<Zakim> MichaelC, you wanted to speak to multiple types
<mck> My point is not make aria-details reference multiple elements but instead reference a single element that is itself a menu or list. No need for multiple IDs in aria-details.
mc: don´t overload media queries, and need the types to be not a predefined list, so need way to filter on pref to show indicator, and separately on the type of indicator you want used, but how do we engineer the indicator of types? can´t overload aria-details for that part
gk: no controlled vocabulary, but human readable label
rs: @@
js: you might want to be able to hide all of them
rs: yeah, default is off
unless user turns it on
in which case they all turn on
js: need default presentation to be unencumbered, it´s a copyright issue
rd: like media queries
but clear not sufficient on its own for some use cases
you could decide to turn on indicators, then turn them off again
so user needs a way to dynamically set
discuss with CSS, API to set media queries
<Zakim> joanie, you wanted to respond to Matt regarding the menu: If one target user group is individuals with cognitive disabilities, a menu of potentially-confusing choices seems like a
mc: massive project, good one but let´s look for other solutions short term
jd: we don´t want to confuse users with choices
if AT knows what a specific user needs
can personalize
might need another property
<mhakkinen> +q
maybe core ARIA has a starter vocabulary
that other modules could extend
gk: let´s not build something before it exists
very small collection of examples right now
in US, getting to ability to access most of text content
but images still a problem
don´t think publishing industry is going to provide descriptions for all that
though in industries like 3d animation, there will be general interest in these descriptions
jgw: how about extensible vocabulary, that can be used in media queries and things that use them
2-level permission model, r and rw
user could allow some apps to set, others only to read
persistent storage
then you have the pieces for a media queries solution
jd: example of read vs read/write access?
jgw: app to configure my prefs would have rw
a book might just have r access to customize but not change my prefs
mh: for ETS it´s not always alternative descriptions, sometimes they daisy-chain
e.g., tactile version that you 3d print etcc.
gk: how do you decide what student gets?
mh: personal needs profile
since we´re testing, we can´t increase cognitive load
really need clean ui model
rs: media query has multiple values
is there a set?
mh: yes
rs: how should you set the values?
jgw: via permission model
mc: or plugin to set media query setting
jgw: permission model gives user flexibility
this is just a top-of-head proposal though
rs: browsers going to standardized extension model
if could do via plugin
would that work?
jgw: believe so
though user has to install the plugin
mc: mc this sort of plugin could get mainstreamed pretty quickly
rs: so let´s ask CSS for extensible media queries
mc: that´s a huge project
worth starting discussion, but let´s not predicate our solution on it
rd: there was an old discussion
jgw: think they are leaving open to extensibility
mc: but not sure they want to work out the actual mechanism
js: houdini?
<Ryladog__> https://css-tricks.com/developing-extensible-html-css-components/
<Zakim> Gottfried, you wanted to support Joanie in that personalization is context-specific, not just user-specific
jgw: have heard a ¨integrate if you figure out security model¨ message
gz: think this is more complex than we think
not just personal preferences
but task context
equipment you´re using
environment
most important is user is in control
if interim there´s just a list of choices, maybe that´s good for now
risk with media queries is author makes the decision
gk: in MathML, publishers need to be happy with presentationn
maybe a media query could allow swapping what user sees
mc: that makes users only see certain things
<Zakim> MichaelC, you wanted to not boil ocea yet
mc: before we boil the ocean let´s make a cup of tea
mh: need this!
mc: sounds like we need one or 2 media queries from CSS WG (very concrete ask)
tell CSS we want extensibility, not asking for yet
and we still need to sort out the mechanism for taking advantage of this
rs: need extensibility of media queries because they only relate to OS features
mc: maybe that´s a case to end that restriction
... so we have identified new engineering, but not in ARIA
this meets the use cases, right?
js: we´re ok with plugin?
rs: it´s a big step forward
and allows innovation
mh: not hot on plugins
what will it do?
rs: depends what you want
seriously, will set media attributes based on user preferences
how that is done can vary
mh: we target a wide variety of devices
js: with plugin, you can control its availability
gk: if a media query isn´t supported, it´s gonna fail
with the plugin, you can have better support
gz: chicken / egg issue
allow user to pick
<Ryladog__> scribe: Ryladog__
<scribe> ScribeNick: Ryladog
<Ryladog__> Roman: Before breakI had a question, it is infact possible to hook into the media query thing
<Ryladog__> Roman: It plug-in doesnt answer the UseCase for the user that doesnt want to have a description all of the time. I amnot sure it is simpler thanhaving the non-plugin approach
<richardschwerdtfeger> http://browsers.about.com/od/howtousemobilebrowser1/ss/How-To-Use-Safari-Extensions-On-The-Iphone-Or-Ipod-Touch.htm
<Ryladog__> ??: plugin for both things?
<Ryladog__> RS: The plugin is for the media Queries
<Ryladog__> ??: What are we asking about extensibility or plugin?
<Ryladog__> JS:The difference may just be political - who does it
<Ryladog__> ??: dePub is in talks with CSS they are talking about a Media Query extension for CSS
<Ryladog__> JS: And we are just hearing about this now?
<Ryladog__> JS: Why woudnt show ARIA details not work for that?
<Ryladog__> RS: If you have in a plugin, you write your own media query andyou are able to write this standrardized media query, you are able to write your own
<Ryladog__> RS: I just posted a link, you can right a media queries to iOS
<Ryladog__> JS: We needto coordinate of this, if you are talkingto CSS - we need to know about it
<Ryladog__> JS: We are not the only ones with this kind of need. There are two sides, the tech solution, and there is the political side. One or the other W3C group for something to happen. Either WebPlatform or CSS, And it seems like CSS is going to be the easier one
<Ryladog__> MH: ETS is really interested in some sort of solution, this is a real need for us. If we can get this commonality
<Ryladog__> MH: We need a common user experience for how students address and see this
<Ryladog__> MH: It spans the age range, from very young kids to very adult learners. It has to work from K to elder
<Ryladog__> JW: I think what Rich was suggesting is a bit different what I was suggesting, but either is fine
<Ryladog__> JS: We just have to make this part of the agenda
<Ryladog__> GK: With this media Query for Diagrammer, the would expose the aria details
<Ryladog__> JS: You are writing theplugin
<Ryladog__> RS: You can with this icon know there is more details.. You dont have the attribute slector, you can change what type of icon and then you can show the extened description on the page or not
<Ryladog__> JS: Well, you turm it on
<Ryladog__> RS: If you had an image, lets say you want to turn on that I want to see ED. I can expose a teddy bear
<Ryladog__> HK: You have theteddy bear, but does the description always have to show up on the page?
<Ryladog__> RS: No. let say I decide I dont want to see ED> Then you dont see the teddy bear. In the plugin you can define how you want to see things
<Ryladog__> RS: Also, I have ED turned on and I want to show this x kind of thing for ED.
<Ryladog__> GK: Either you have a teddy bear, the publisher h the option of showing it or not
<Ryladog__> JW: If you had this you could implement the whole of personalizations
<Ryladog__> RS: Yes
<Ryladog__> JW: It would be good to have web applicationshave this kind of control
<Ryladog__> KHS:That is the long term vision we were talking with the future for Web Platform
<Ryladog__> RS: It takes an act of God to get this done with the browsers. With a plugin you avoid all of that
<Ryladog__> JS: You can do it and you can fix it in 6 months if you want. We wont get that if we try to go through web platforms and the browsers
<Ryladog__> GK: If you have an option to turn on teddy bears or not
<Ryladog__> RS: With MQ it doesnt matter what rules you have to implement
<Ryladog__> JS:I beleive this is emenentbly grant-able
<Ryladog__> RS: You just need a mechanism toimplement it
<Ryladog__> Roman: CSS has said that there is some way for scripts to clain support. Such as "I support MathML"
<Ryladog__> RS You dont wwant the page author to set that do you?
<Ryladog__> MH: But where is that comingfrom?
<rdeltour> https://groups.google.com/d/msg/epub-working-group/jaSz8Fh9j90/Z5mMSnLIAQAJ
<Ryladog__> MH: How do we get that?
<Ryladog__> JS: I think ARIA details is it
<Ryladog__> JW: So I thinkfor RichProposal there would be anextension that has the authority to set the MQ flag.
<Ryladog__> JW: The extesion would implement the flags
<Ryladog__> SJ: And I think it would cover MathML and others
<Ryladog__> MH: I can set LV, Tactile, then it would load the other
<Ryladog__> SJ: ARIA details is just a container
<Ryladog__> RS: OK what content doI want toshow?
<Ryladog__> JW: Define the new MQ ame andset the value
<Ryladog__> RS: You could probably define what you want it toload
<Ryladog__> JW: I understand Rich proposal, I think it is very interesting...
<Ryladog__> JS: None of the browser vendors came to this meeting even though I advertised it
<Ryladog__> JS: We need to talk in advance
<Ryladog__> Coffee Break
<Ryladog__> JS; Thank you!, Resuming at 3:30
<janina>
<jasonjgw> scribe: jasonjgw
<janina> Chair: Janina
Shane: proposes to present an update on what is happening in the Web Payments activity.
There is a series of specifications, none of which has an explicitly defined user interface. Two of the specs have implicit user interfaces.
The provisions for accessibility relate to timeouts and the Web Payments WG is prpared to introduce notes addressing the accessibility issues.
The Web Payments API spec addresses timeouts. When the user opts to proceed with a urchase, the user interface is defined by the user agent.
If, during the payment process defined by the UI in the UA, the UA has to query the server for additional information, and if the query to the server is never resolved, the UI has to respond appropriately to the timeout condition - whatever "appropriately" means.
The Payment App spec is the second specification that addresses timeouts.
This spec discusses the user interface of the payment app (e.g., selection of payment methods) and there are opportunities for timeout issues there.
In a meeting on Thursday with Web Payments IG, a draft Web Payment User Requirements document (under development) will be discussed.
For accessibility purposes, the user interfaces should be as stateless as they can be and free from access barriers.
Katie: notes several facotrs in the design of Web Payments that need to be balanced appropriately, accessibility among them.
Shane argues that the system needs to be open enough to enable the needs of different users to be satisfied (by different solutions/applications).
Shane and Katie will also discuss the Web Payments Task Force in their meeting with the Web Payments Interest Group.
Lisa: success criteria have been proposed by COGA extending WCAG requirements regarding timeouts, e.g., don't lose user data in the event of a timeout.
Katie notes that this raises privacy issues.
Lisa: there are also proposals under development which preclude the adding of mechanisms that are likely to confuse users.
Example: number of units to purchase is automatically populated to a value greater than 1.
Lisa: it needs to be made clear (in machine readable form) whether a financial transaction can be reversed after submission.
The user agent can then highlight it in the user interface.
Shane: there has been discussion of allowing merchants to provide this kind of information during the purchasing process. This won't be included in the first version of Web Payments but remains on the agenda.
Lisa: it has been proposed that a simple mechanism be required that makes it easier for the user to reverse a transaction at the (pos-submission) confirmation step.
Correction: pre-submission - correcting the form fields before submission.
The user interface should identify the kinds of charges that will be included at the beginning of the purchasing process.
Examples: taxes, shipping and handling charges, etc.
Shane: Web Payments will provide a more consistent checkout experience for all users.
Example: a purchasing UI is supposed to show the list of shipping options and associated charges. This would be consistent across all purchases made by the user across all sessions.
The UA provides its own UI for the purchasing process, but this UI can be overridden by the merchant's Web application.
Shane notes that Web payments UIs will automatically complete form fields, simplifying the process for the user and reducing cognitive demands.
It is agreed that payment-related user interfaces should be flexible in handling variations in data entry, e.g., date formats (Lisa's example), abbreviations (e.g., in addresses).
Lisa notes localization issues that can confuse users.
<Lisa_Seeman> https://rawgit.com/w3c/coga/master/extension/rewroded%20sc%203.html
Responding to Janina, Shane clarifies that the presentation on Thursday is expected to contribute to a dialogue with participants in Web Payments IG.
Shane hopes for information from Web Payments IG about user experience issues that they're aware of.
<Gottfried> scribe: Gottfried
scribe: introductions ...
Presentation by Johannes.
Johannes: Trying to standardize the APIs rather than scripting languages.
(Rich joining)
scribe: Using standard browser and standard technologies. Goal is that everybody can still use their own authoring tools, just change APIs.
... Example of a can machine. How to cover all user groups?
... What to do with multiple machines?
... Multiple personal devices of users.
Rich: ISO/IEC 24752 Universal Remote Console has done this.
... Web interface gets an abstract description of the machine functionality. Web interface knows what the user needs.
Johannes: We don't want to be Silo n+1.
Gottfried: URC was developed a longer time ago - good to have a new approach that builds on it but is more open.
Johannes: What if the web browser knows exactly what the user needs?
... Web standards as "narrow waist" of IoT.
... Servient = Server & Client at the same time
... Decouple the frontend from communication between devices.
... Authentication based on OAuth, but token format not standardized. We use plugfests for converging towards interoperability.
... Sign in via an identity provider.
Rich: We want to switch to a decentralized approach in Horizon 3, e.g. through blockchains.
... We have considered this in many telecons. Functions and security go along with each other.
... Standardization on: scripting API, Thing Description, Bindings to common protocols and platforms
... Thing Description: A things explains itself
Gottfried: In 24752, this is the Target Description + Socket Description
Johannes: We have talked to somebody from Eclipse.
Jason: Standardized semantics?
Johannes: Thing Description is in JSON-ID, and you can link into any RDF-based context.
... We do not have classes of devices. We only specify the format.
... We didn't want to go too deep into domains.
Jason: If every manufacturer would come up with their own set of functions...
(Sebastian Käbisch joining)
Johannes: Somebody from Schema.org is supporting us.
Jason: In 24752, you could write a generic application that would make a user interface based on the description of the things.
Johannes: Demo at TPAC on Wednesday. One of the Things Description tasks force will show that different UIs will be generated based on the fingerprint of the user.
... Also using an ARIA-based web interface.
... Bindings - using a resource layer based on HTTP and CoAP, but other technologies will be added
... Restricted set of operations on resource. Abstract interaction can be expressed in multiple protocols.
Lisa: COGA tf has proposed different sets of symbols and terms.
Johannes: Not aware of that.
Lisa: If there is a semantic for the functionality, an alternative icon could be loaded.
... Most critical features need to be identified for a device as the most essential functions.
(Michael Cooper joining)
(Sebastian Käbisch had to leave a while ago)
Johannes: Semantics can be expressed in triples. We intend to have a container for semantics.
(Michael leaving)
Jason: Can we define standard terms for standard functions?
Janina: Like i18n.
Gottfried: Personalization can be facilitated by third parties contributing alternative ui resources, e.g. icons, sign language videos, input patterns.
Janina: You should work with Gottfried on the experiences of URC.
Gottfried: Main challenge is that designers think visually.
Johannes: Our main problem is silos, i.e. there is an app for every device
... We are in contact with various networking platforms: OCF, openHAB, OPC, oneM2M, oma
Jason: Users don't want to have an application for every piece in their environment. User interface should consistently present the devices and allow the user to interoperate with them.
Janina: And to travel with them.
Lisa: Cognitive access is like different languages.
Gottfried: Which components are in charge of personalization?
Johannes: User interface is out of scope for the architecture.
Gottfried: Sometimes you will need the thing to help produce the UI, e.g. providing a photo of itself.
Johannes: The standard should be modular - other technologies can be built on top.
Bob: Is there a permission model what devices are allowed to do?
Johannes: Everything is based on REST. A token can contain identification and authorization with the request.
... Have to leave now. Hope for more exchange and user stories on life quality.
Janina: How hard should we press with a meeting with Web Authentication? We could meet tomorrow, but they did not respond to our request yet.
... So i will push for a meeting tomorrow.
... They need to understand that they need to work on this with us, and walk us through their API.
... Hope we can have this at 1pm or 1:30pm.
... After that, we will meet with EO.