Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)
Hi, David- The preferred format for comments is actually just plain email. Many of the people on this list use email clients that only display as text. I understand that many organizations use formats such as Word or PDF for official liaisons, but W3C prefers more accessible plain text or HTML formats. It is much easier to process and respond to comments that are sent as text email. It is also useful to break comments down to one topic per email, to facilitate threaded conversations. If you could please resend your comments as one or more emails in plain-text form, that would be very helpful and greatly appreciated. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF David Rogers wrote (on 8/1/08 7:41 AM): Dear Art, Marcos and all, Please find attached the second set of OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call as outlined in my last email. The relevant text from the document is extracted below: Expressing Widget Dependency Information in Widget Packaging Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This proposal is intended as input to the W3C Web Applications work group and represents a snapshot of current discussions on including Widget Dependency Information for both heterogeneous (e.g. Mobile) and homogeneous (e.g. PC) environments in the Widget Configuration Document as defined in the W3C Widget Packaging and Configuration specification (Section 6: Configuration Document). Terminology The following terms are used in this document: Widget Package - A collection of resources required by a widget (including a Widget Configuration Document) that is packaged for distributive purposes (from W3C). Widget Configuration Document - an XML document that has widget as its root. Used to describe the configuration of a Widget Package (from W3C). Widget Dependency Information - a combination of Resource Information and Device Capability Information that may be included in a Widget's Configuration Document. Widget Dependency Information is a super-component of Resource Information and Device Capability Information. Resource Information - a collection of references and/or inferences to External Widget Resources (e.g., Widget Packages, APIs, Javascript, CSS, XSLT files and packages) that are not included in a Widget's Packaging. Resource Information can be mandatory or optional (see definitions in proposal below). Resource Information is a sub-component of Widget Dependency Information. Device Capability Information - a collection of references and/or inferences to Device Capabilities either mandatory or optional (see definitions in proposal below) to provide the functionality of a widget. Device Capability can be hardware-based (e.g., Operating System, Provision of device features such as Camera, etc) and/or software-based (e.g., Specific Browser is available, Specific codec is available, etc). Resource Information can be included either as required (mandatory) or optional in order to provide the functionality of a widget. Device Capability Information is a sub-component of Widget Dependency Information. Requirements Widget Dependency Groupings The Widget Dependency Information required in Widget Packaging falls in to two categories: 1. Resource Information. External Widget Packages, Device APIs (Address Book API, Location API, etc) / Non-Device APIs (e.g. Javascript Toolkits such as Dojo, Yahoo UI, etc) and other web-based resources (e.g., CSS, XSLT, Folders) required to provide the functionality of a widget. 2. Device Capability Information. Minimum environment configuration required to provide the functionality of a widget (e.g., a camera, a particular sub-class of device, etc). In addition, each component of Widget Dependency Information should either be: 1. Mandatory - a Resource must be present to install (if required), load and run the core features of the
Re: XDomainRequest Integration with AC
Sunava Dutta wrote: In offline conversations with Jonas on the topic of supporting the url syntax I think Jonas mentioned a good point regarding supporting URL for the private scenario. Namely, in caching scenarios allowing the URL to be sent in the response header if mistakes happen (for example Vary by origin header is not sent or ignored) doing so will ensure that it fails securely. I'm not so sure about the value for the public data scenario (other than consistency). Here's what I came up with, feel free to add on or elaborate. Just to clarify, your proposal is that when Access-Control-Allow-Credentials *is not* set to true we should only allow the value * for Access-Control-Allow-Origin? Whereas when Access-Control-Allow-Credentials *is* set to true we already only allow the URL syntax for Access-Control-Allow-Origin. Pros (of supporting URL syntax in public scenarios) * Supporting URL allows for a site to return data that's related to a particular site, but is non user specific (no creds) This can be accomplished either way since the server can use the Origin header if it wants to send different data for different requesting servers. I'm not really sure that that is a usecase that we have designed much around though. Cons * A better architecture here is that a site will rely on the Access-Control-Origin header to determine the site and then decide to send the data or not. Along those line it as a few teammates said it seems wasteful to support URL syntax for the public scenario as we don't want the data to be sent on the client and dumped. The server should simply not send the content if the Origin is not what is desired. Please note that the header is simply called Origin now, and has been for quite some time. * The second problem that comes to mind is that clients cannot be trusted. The resource server essentially is relying on the client to enforce the domain check. However since this is anonymous access, the client could well be evil.com's server, which would simply ignore the URL and grab data. The resource server has no way of telling who the request party really is -- it is just an anonymous HTTP client. This may instill a false sense of security for server operators. * The third challenge here is that the access-control-origin header may be spoofable therefore this scenario is not reliably solved. Like you point out, if you can't trust the client then your initial proposal for the server to look at the Origin header does not work either. However this seems to be the case no matter if we support the URL syntax for public data or not. So I don't see how this is a pro or con one way or another. All three cons you are listing seems to come down to that in the public data scenario the client can't be trusted, which does seem partially true. The way I see it is this: Pros of supporting the URL syntax for public data: * Simpler and more consistent specification. I.e. the URL syntax is always allowed and we are only forbidding the combination of wildcarding and sending cookies at the same time. * Allows a server which serves private and public data. When the server receives cookies it can customize the result for the user, when no cookies are sent it just sends back a generic response. In both cases it echoes back in the Access-Control-Allow-Origin response header the URL it received in the Origin request header. * Allows mashup sites inside a corporate firewall. These servers might serve company private data and wants to use the Access-Control spec to allow the data to be mashed up. However it does not want external websites to load such data. It does this by only echoing back in the Access-Control-Allow-Origin header the URL from the Origin header if the Origin is an intranet server. In this case the client can be trusted even in the public data case since only browsers installed on company client desktops can issue requests to the site, evil.com is blocked by the firewall. Cons of supporting the URL syntax for public data: * There is a risk of a false sense of security. I.e. a site might send private data from a URI and protect it only by sending Access-Control-Allow-Origin: trusted.com. The spec does state that such a response should not be exposed to evil.com. However if evil.com made such a request server-to-server it can of course ignore this and still read the data. A couple of notes: The last 'con' might happen anyway if the server just looks at the Origin request header and deciding whether to send the data or not based on the value of that header. So for the false sense of security argument to hold we would also be required not to send the 'Origin' header with public data requests. Similarly the 'Referer' header should not be send since it carries the same risk. The second 'serves private and public data' was something that Hixie mentioned that google might want to do in the future. If a request
RE: Accessibility requirement
WCAG 2.0 does have such a definition, and is in CR. It should be a W3C rec within a year, so seems like the appropriate doc to reference. As to your concerns related to WCAG itself, I'd be happy to follow up with you offline or on the WCAG list on those. Thanks, Cynthia -Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 10:50 PM To: Arthur Barstow Cc: Cynthia Shelly; public-webapps Subject: Re: Accessibility requirement On Tue, Jul 29, 2008 at 4:15 AM, Arthur Barstow [EMAIL PROTECTED] wrote: Marcos, Cynthia, Perhaps requirement #37 as currently written [1] is overly prescriptive. For example, rather than trying to enumerate the sub-requirements for the other language (i.e. the non-HTML language), there could just be a reference to a spec/doc that defines the requirements for a language to be accessible. Also, the last sentence appears to be a statement about a Widget instance (and not a requirement for a Widget UA) and hence should not be normative. Combining the above comments, I get: [[ A conforming specification must specify that the language used to declare the user interface of a widget be either HTML or a language that is accessible as defined by [?SOME-WAI-RESOURCE?]. ]] I'm willing to point the Requirements doc to WCAG 1 or 2 if the group wants me to. I personally don't agree with a lot of the things in WCAG 1 or 2, but if it's the best we have so be it. It would be helpful if others with more experience in this area could provide some guidance on how to proceed. -- Marcos Caceres http://datadriven.com.au
[wbs] response to 'Do you approve advancing the Element Traversal spec to Candidate Recommendation?'
The following answers have been successfully submitted to 'Do you approve advancing the Element Traversal spec to Candidate Recommendation?' (Web Applications Working Group) for Travis Leithead. - Do you approve advancing the Element Traversal spec to Candidate Recommendation? Do you approve advancing the Element Traversal spec to Candidate Recommendation? * (x) Yes * ( ) No Rationale: Comments (or a URI pointing to your comments): These answers were last modified on 1 August 2008 at 22:16:05 U.T.C. by Travis Leithead Answers to this questionnaire can be set and changed at http://www.w3.org/2002/09/wbs/42538/ET-Advance-2-CR/ until 2008-08-08. Regards, The Automatic WBS Mailer
Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)
Hi Doug, All, below is the plain text edition of the email. It can also be found in the archive: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0302.html --- Dear Art, Marcos and all, Please find attached the second set of OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call as outlined in my last email. The relevant text from the document is extracted below: Expressing Widget Dependency Information in Widget Packaging Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This proposal is intended as input to the W3C Web Applications work group and represents a snapshot of current discussions on including Widget Dependency Information for both heterogeneous (e.g. Mobile) and homogeneous (e.g. PC) environments in the Widget Configuration Document as defined in the W3C Widget Packaging and Configuration specification (Section 6: Configuration Document). Terminology The following terms are used in this document: Widget Package - A collection of resources required by a widget (including a Widget Configuration Document) that is packaged for distributive purposes (from W3C). Widget Configuration Document - an XML document that has widget as its root. Used to describe the configuration of a Widget Package (from W3C). Widget Dependency Information - a combination of Resource Information and Device Capability Information that may be included in a Widget's Configuration Document. Widget Dependency Information is a super-component of Resource Information and Device Capability Information. Resource Information - a collection of references and/or inferences to External Widget Resources (e.g., Widget Packages, APIs, Javascript, CSS, XSLT files and packages) that are not included in a Widget's Packaging. Resource Information can be mandatory or optional (see definitions in proposal below). Resource Information is a sub-component of Widget Dependency Information. Device Capability Information - a collection of references and/or inferences to Device Capabilities either mandatory or optional (see definitions in proposal below) to provide the functionality of a widget. Device Capability can be hardware-based (e.g., Operating System, Provision of device features such as Camera, etc) and/or software-based (e.g., Specific Browser is available, Specific codec is available, etc). Resource Information can be included either as required (mandatory) or optional in order to provide the functionality of a widget. Device Capability Information is a sub-component of Widget Dependency Information. Requirements Widget Dependency Groupings The Widget Dependency Information required in Widget Packaging falls in to two categories: 1. Resource Information. External Widget Packages, Device APIs (Address Book API, Location API, etc) / Non-Device APIs (e.g. Javascript Toolkits such as Dojo, Yahoo UI, etc) and other web-based resources (e.g., CSS, XSLT, Folders) required to provide the functionality of a widget. 2. Device Capability Information. Minimum environment configuration required to provide the functionality of a widget (e.g., a camera, a particular sub-class of device, etc). In addition, each component of Widget Dependency Information should either be: 1. Mandatory - a Resource must be present to install (if required), load and run the core features of the widget. In the case that a mandatory dependency cannot be provisioned a fatal error may occur. 2. Optional - a Resource may be present but could be provisioned later and/or at runtime or not at all to run peripheral / non-core functionality of the widget. In the case that a optional dependency cannot be provisioned a non-fatal error may occur. The W3C Widget Packaging specification may wish to define how the widget handling environment will treat dependencies marked as Mandatory and Optional. Resource Information and Device Capability Information requirements are discussed below. Widget Dependency Information A widget developer
