Re: [Widgets] Requirements LC
On Wed, Jun 18, 2008 at 8:41 PM, timeless [EMAIL PROTECTED] wrote: On 6/18/08, Marcos Caceres [EMAIL PROTECTED] wrote: R28. Network State Change Events A conforming specification must specify a means that allows authors to check if the widget resource is connected to Web. A conforming _the_ Web However would you please explain what it means? Yeah, the Web was a poor choice of words:) I've changed it to network, but left network to be defined by a conforming specification. As you pointed out, the concept of connecting to/disconnecting from a network is quite complex. I've I have an iPod Touch and it's connected to a WiFi access point which asks me to sign in, and doesn't let me go anywhere until i do (but resolves all DNS entries to IP addresses which it answers with the same annoying page), am I connected to /the/ Web? I guess. specification must also specify a mans by which connection and a /means/ fixed. disconnection events can be captured by an author through script. Motivation: Current development practice or industry best-practices, ease of use. Rational: Rationale ? right:P Fixed. To allow authors to programmatically capture when a the widget user my spell checker doesn't approve of programmatically, but I'll deal w/ it later. a the is wrong. Fixed. agent has got or lost a connection to the Web. don't use got changed to acquired. R30. Device Specific APIs and Services A conforming specification should specify a mechanism, either through an API or through the configuration document, that allows instantiated widgets to bind to third-party APIs that allow access to that = which Fixed. device-specific resources and services. A conforming specification is not required to specify any APIs to device specific resources or services, but shouldprovide some means of binding to those APIs if should _ _ provide they are available. Fixed. R35. Configuration Document Data A conforming specification SHOULD specify a means that allows authors to access any relevant data they declared in the configuration document for the widget resource. i don't understand this, and for privacy reasons, I'm fairly certain i disagree with it as written. This just means that you should be able to get at the stuff in the config.xml file (so you don't need to declare the metadata again in the start file). How would you suggest I rewrite it? To allow author to open a URL in the default system web browser. For example, in an news aggregator widget, to allow the end user to in /a/ news Fixed. Many thanks for finding all those errors! If you have any more comments about the other requirements, I sure would like to hear them. -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
Re: Improving Communication and Expectations
Hi Marc, On Thu, Jun 19, 2008 at 6:05 AM, Marc Silbey [EMAIL PROTECTED] wrote: Hey Marcos, I totally understand why you would be frustrated by our behavior here. I owe you, Anne, Art and the rest of the WAF group an apology for falling off the radar without telling you where I was going. I am definitely sorry for that. I'm sorry I didn't raise this issue earlier (and more politely). I remember having good conversations with you and others at the Boston f2f on access control and then in email shortly after. I stopped attending WAF calls and we stopped giving feedback on access control for a long while so I can understand why you think we vanished to do our own thing. This was mostly due to the fact that my role in IE changed a little over a year ago and I started working more on accessibility (PF WG) and then at a different capacity altogether. When I was active in WAF, it wasn't at all clear to me that members of the Web API WG intended to apply the WAF's access control model directly to XHR. As a result, I didn't make our XDR team aware of Web API's work. We want to avoid this in the future by having more IE folks participate in the various WGs. It also helps that Web API and WAF are merged now too. I want to step back for a moment; I joined the IE team during our rebirth if you will. We largely have a new team of people working on IE now and you're starting to see some of us be a part of the W3C. I'll be the first to admit that we're making mistakes during our reentry into the standards conversation. We care deeply about our common web developer and we really want to work with you and others in the working groups to improve standards. I think everyone in the WG shares those goals. We're always open to constructive feedback on how we can better engage. I'm hopeful that we can work through the group's climate and technical issues together quickly. It goes without saying that we have a lot of respect for the folks in the group and so I'm also hopeful that our feedback will be taken seriously. I guess the simplest thing is to communicate. That does not mean anyone expects Microsoft to disclose product information. If you guys are busy, and need to drop off for a while let us know. We all rely on Microsoft, who has the largest market share in this space, to be engaged so we don't end up with you guys dropping an XDR-bomb on the group and more fragmentation on the Web. I say this because all other desktop browser vendors actively participated in the design of Access-Control and chose not to run off and do their own thing (but they could have). When you guys run off and do your own thing (as was the case with XDR), people may start coming up with all sorts of ridiculous conspiracy theories [1] as to why you did that. Kind regards, Marcos [1] http://datadriven.com.au/2008/06/18/ie8-xdomainrequest-conspiracy-theory/ -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
[Widgets] Requirements LC
To which Timeless replied... -- Forwarded message -- From: timeless [EMAIL PROTECTED] Date: Thu, Jun 19, 2008 at 7:44 PM Subject: Re: [Widgets] Requirements LC To: Marcos Caceres [EMAIL PROTECTED] (you didn't reply to the list) On 6/18/08, Marcos Caceres [EMAIL PROTECTED] wrote: R35. Configuration Document Data A conforming specification SHOULD specify a means that allows authors to access any relevant data they declared in the configuration *relevant data* document for the widget resource. On Thu, Jun 19, 2008 at 11:20 AM, Marcos Caceres [EMAIL PROTECTED] wrote: If it was irrelevant, it would not have been declared in the config. I don't understand why you think it is irrelevant? your words, not mine. I think you should just delete the word relevant. note that I'm reading everything *very* literally. Yes, that is possible (using XHR to load the config from within the package), but then you have to walk an XML tree which sucks. The other way is to use the properties that we have bound to the Widget object. Check out http://dev.w3.org/2006/waf/widgets-api/Overview.src.html yeah, i'm sure such things are possible in some theoretical sense, but i want to make sure that the API you're asking for doesn't specifically do/enable this.
Re: [Widgets] Requirements LC
On Fri, Jun 20, 2008 at 5:04 PM, Marcos Caceres [EMAIL PROTECTED] wrote: To which Timeless replied... -- Forwarded message -- From: timeless [EMAIL PROTECTED] Date: Thu, Jun 19, 2008 at 7:44 PM Subject: Re: [Widgets] Requirements LC To: Marcos Caceres [EMAIL PROTECTED] (you didn't reply to the list) On 6/18/08, Marcos Caceres [EMAIL PROTECTED] wrote: R35. Configuration Document Data A conforming specification SHOULD specify a means that allows authors to access any relevant data they declared in the configuration *relevant data* document for the widget resource. On Thu, Jun 19, 2008 at 11:20 AM, Marcos Caceres [EMAIL PROTECTED] wrote: If it was irrelevant, it would not have been declared in the config. I don't understand why you think it is irrelevant? your words, not mine. I think you should just delete the word relevant. note that I'm reading everything *very* literally. I removed the word relevant. Yes, that is possible (using XHR to load the config from within the package), but then you have to walk an XML tree which sucks. The other way is to use the properties that we have bound to the Widget object. Check out http://dev.w3.org/2006/waf/widgets-api/Overview.src.html yeah, i'm sure such things are possible in some theoretical sense, but i want to make sure that the API you're asking for doesn't specifically do/enable this. Arve? What does the proposed security policy say about this? Can XHR be used to GET resources inside the package? -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
[widgets] Device Specific APIs and Services
Hi,
What follows is an *extremely rough* strawman proposal to address
R30. Device Specific APIs and Services, of the widget requirements
document. This proposal is intended for discussion and is deliberately
thin on technical details.
Requirement 30 of the Widgets requirements document is as follows:
A conforming specification should specify a mechanism, either through
an API or through the configuration document, which allows
instantiated widgets to bind to third-party APIs that allow access to
device-specific resources and services. A conforming specification is
not required to specify any APIs to device specific resources or
services, but should provide some means of binding to those APIs if
they are available.
Motivation:
Current development practice or industry best-practices, ease of use.
Rationale:
To endow widgets with functionality beyond what is currently available
to HTML documents, allowing widgets to be used as means to bridge
special device capabilities and operating system services with data on
the Web. Examples of device-specific services and resources that could
be made available through script include cameras, SMS, geolocation and
address book. There are other WGs working on this requirements such
as the Ubiquitous Web Applications Working Group (UWA-WG), and the
Open Mobile Alliance (OMA) Device Capabilities Working Group.
=The Proposal=
There are two aspects to the proposal: a declarative aspect and
programmatic aspect.
Declarative aspect:
The declarative side would involve declaring the intention to use an
API that may or may not be part of the standard set of APIs that
shipped with the widget engine. We declare the intention to use an API
in the configuration document for security purposes (the config.xml
file cannot be written to by the widget engine and the config file can
be digitally signed). APIs are identified as resources via URIs. For
example:
widget
access network=true
requires id=gps
src=http://gps.w3.org/api.jar;
type=application/jar
kind=api /
/access
/widget
The interfaces that bind this binary component to JavaScript would
need to be standardized and I have no idea what they would look like
at this point.
Programatic aspect
At runtime, in we would need something like the following interfaces:
interface APILoader{
attribute APILoader APILoader(DOMString id); // the id declared
void load(); //load the API
void cancel(); //cancel loading
//progress events...
attribute EventListener onLoad;
attribute EventListener onProgress;
attribute EventListener onError;
...etc...
}
interface api{
Object bind(); //binds the api to runtime
enum interfaces(); //returns a list of methods
void unbind(); //removes the binding from memory
}
Example usage:
apiLoader = new APILoader(gps); //must match an id in config.xml
apiLoader.onLoad = function(loadedAPI){
try{
gps = loadedAPI.bind();
loc = gps.getLastLoc();
catch(e){
}
}
apiLoader.onError = function(loader){}
apiLoader.load();
--
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org
Re: Initial input for discussion of Widget security model
On Thu, May 1, 2008 at 1:33 AM, Arve Bersvendsen [EMAIL PROTECTED] wrote: Attached is a document providing some initial input on a security model for a widget, that should provide a rough draft for providing the/a widget security model. Note that the document is not to be treated as input for specification text, and it needs substantial work and review before any such thing can take place. I'm just wondering how we should proceed with the Security input? My preference has always been to create a Widgets 1.0: Security spec. However, we need someone to edit it. I am willing to help edit it, but would not want to take a leading editorial role. kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[Widgets] Requirements LC Comment Tracker
Mike(tm) Smith has set up a Last Call comments tracker for the Widgets 1.0: Requirements document: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-reqs-20080625 All comments will be tracked through there. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Call for Review: Last Call WD of Widgets 1.0 Requirements
Hi Sean, On Wed, Jun 25, 2008 at 11:37 PM, Sean Mullan [EMAIL PROTECTED] wrote: Marcos Caceres wrote: However, do you think we should be referencing version 4? has there been much uptake of v4? Not sure, but I would be more inclined to reference RFC 5280: http://www.ietf.org/rfc/rfc5280.txt Ok, I've updated the reference. It now reads: [X.509v3] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson, S. Boeyen, R. Housley, and W. Polk. May 2008. RFC5280 is available at http://www.ietf.org/rfc/rfc5280.txt For our record keeping of LC comments, could you please confirm that the Working Group has addressed your comments. Thank you again for taking the time to do the review. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] ETags and Automatic updates
On Wed, Jul 2, 2008 at 5:48 PM, mike amundsen [EMAIL PROTECTED] wrote: While ETag is the name of an HTTP Header, the _contents_ of the ETag has nothing to do with HTTP. Yep, I am aware of that. No matter the delivery format, a hash value that represents the widget can be supplied. It can be done as an HTTP Header, as an attribute in the XML that represents the widget (as in your example), Or as some other element delivered in the package itself. I'm sure it could be done. But how can this be done easily with Apache or IIS? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] ETags and Automatic updates
On Thu, Jul 3, 2008 at 3:34 PM, Julian Reschke [EMAIL PROTECTED] wrote: Marcos Caceres wrote: On Wed, Jul 2, 2008 at 10:17 PM, mike amundsen [EMAIL PROTECTED] wrote: Marcos: snip I'm sure it could be done. But how can this be done easily with Apache or IIS? /snip Since Apache and IIS are HTTP servers, you can use the HTTP Headers to send hash data. Using the ETag is the most common, but if you like, you can propose a new HTTP Header (X-Widget-Hash). I know I should be able to do to send HTTP headers, but the question is still *how*? I mean, for Apache, do I modify the .htaccess file? if so, what do I put in there? If I can get a web server to send a custom ETag or Widget-Hash easily enough, then the solution is doable so long as its also easy to replicate in IIS and on any other web server. *Sending* a custom etag is not sufficient; Apache needs to be aware of it, otherwise all the conditional HTTP stuff will stop working. Yeah, this is kinda what I'm getting at :) FWIW, if it comes down to having to introduce a custom HTTP header, then I definitely think we should dump this solution. What about Content-MD5? Not supported by IIS, AFAIK. In Apache, sure, but, as [1] states, Note that this can cause performance problems on your server since the message digest is computed on every request (the values are not cached). And [2] says It was a bit proof-of-content code I added to Apache, and was never designed to be used in a real web server [1] http://apache.active-venture.com/mod/core3.htm [2] http://mail-archives.apache.org/mod_mbox/httpd-dev/199708.mbox/[EMAIL PROTECTED] -- Marcos Caceres http://datadriven.com.au
Re: Accessibility requirement
Hi Cynthia, On Fri, Jul 11, 2008 at 9:50 PM, Cynthia Shelly [EMAIL PROTECTED] wrote: Hi, I'm a member of wai-pf and wcag, and met some of you at the web apps face to face in redmond recently. I was reading through the widgets 1.0 requirements spec, and came across this accessibility requirement. Wondering why only should and may here, and not must? the reason we have should and may is to accommodate HTML, which is not as accessible as it could be. To have must would mean that HTML4.01 could not meet the requirement. R37. Language Accessibility A conforming specification must specify that the language used to declare the user interface of a widget be either HTMLhttp://www.w3.org/TR/widgets-reqs/#html or a language that is accessible at various levels: it should provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through an non-graphical UI. The declared interface may also be accessible to screen readers, allowing relevant sections of text and functionality to be accessed by non-visual means. Also, I noticed references to google and yahoo web gadgets documentation, and wondered if you'd seen the Windows Live Gadgets SDK [1]? We have, however the spec does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. Please see the Widgets Landscape document [1] for differences between web widgets and widgets as understood by the Working Group. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-land/ -- Marcos Caceres http://datadriven.com.au
Re: Accessibility requirement
On Tue, Jul 15, 2008 at 12:10 AM, Cynthia Shelly [EMAIL PROTECTED] wrote: Interesting... My experience has been that HTML 4.01 can be made accessible if it is carefully coded. WCAG 2.0 has many techniques for this, including for scripted and styled content. While it is true than many (possibly most) DHTML applications have accessibility issues, I do not believe that this is the fault of the standard so much as the authors. Do you have examples of things that cannot be made accessible in HTML 4.01? I agree in principle (though not with WCAG 2.0, but I don't want to start a thread about WCAG 2.0 and accessibility). I guess rather than writing out a list, I can simply cite the ARIA spec [1] as it basically lists some of things that are missing for accessibility in HTML4.01. Fortunately, ARIA has found a home in HTML5 but, from a standardization perspective, that's years away from completion. Widgets, we assume/hope, we package HTML5 applications in the future but we are standardizing, for better or for worsts, on HTML4.01. [1] http://www.w3.org/TR/wai-aria/ -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] - Requirements Working Draft 23 June 2008 Review
specification MUST NOT guarantee event delivery, as there may be cases where a device is running low on power and can not afford to deliver them. R29. Modal Priority [...] (or any of its windows) should to categorize itself should to... should be corrected Fixed. 4.5 User Agents R39. End-user Declared Proxy A conforming specification should recommend that widget user agents allow end-users to explicitly input a proxy server through which all HTTP-based request are made. This requirement should include at the end , or in case of availability, that the system wide proxy is used. This requirement should be a Must Using your text as a guide, I reworded the requirement as: A conforming specification MUST recommend that widget user agents allow end-users to explicitly select a proxy server through which all HTTP-based request are made. In the case where a default proxy has been defined for the operating system, a conforming specification MUST recommend that widget user agents find and make use of any default proxy exposed by the operating system. I also renamed R39 to Proxy Support R40. Automatic Updates This requirement should be a Must fixed. R41. Persistent Storage of Preferences A conforming specification must recommend that a widget user agent implement a means to persistently store user preferences for each instantiated widget. The following should be added after the first sentence: This Storage mechanism must allow to keep the preferences after restart of the widget or on the restart of the user agent. Ok, the requirement now reads: A conforming specification MUST recommend that a widget user agent implement a means to persistently store user preferences for each instantiated widget. A widget user agent MUST persistently retain a widget's preference in the case where a widget is re-instantiated or the widget user agent is restarted. Rationale: To allow widgets to be closed and re-instantiated without the end-user having reset the preferences for an instantiated widget. For example, when using a weather widget, the end-user will want to store the preferred location for weather information, and not be asked to input that information again every time the widget is re-instantiated. And again at the end of this sentence: The same would apply if the user has setup 2 instances of the same widget and would like to view 2 different cities. After closing the widgets, open 2 instances of this weather widget would automatically pick up the 2 pre-set cities. Ok, included your example by modified the text. Here is the rewrite: To allow widgets to be closed and re-instantiated without the end-user having to reset the preferences for an instantiated widget. For example, when using a weather widget, the end-user will want to store the preferred location for weather information, and not be asked to input that information again every time the widget is re-instantiated. The same would apply if the user has instantiated two instances of the same widget and would like to see the weather forecast for two different cities (e.g., Paris and Sydney). When the widgets are re-instantiated, the corresponding weather information would be downloaded to match each widget's city preference. R41 and R42 I would switch them around so that the notion of the multiple instance can be used in the Preference Storage Requirement. Good point. Fixed. R44. Runtime Security Exceptions A conforming specification must specify runtime exceptions for when the API attempts to perform an action it it not authorized to perform. Correct it it fixed. -- Marcos Caceres http://datadriven.com.au
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
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
Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Art, Sally, Steve, All On Mon, Aug 4, 2008 at 9:07 PM, Arthur Barstow [EMAIL PROTECTED] wrote: Sally, Steve, All FYI, Cynthia Shelly [CS] submitted comments that are similar to the ones you submitted regarding requirement #37 [37] of the Widgets Requirement LC WD [LC]. Both Marcos [MC] and I [AB] replied to Cynthia's comments. We agree the wording in sentences #2 and #3 needs work and the tentative resolution is to replace this requirement with text like: [[ 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 [WCAG-2]. ]] The text as it stands today is as follows. I have not had a chance to fully address everyone's feedback on this thread yet but will do so by the end of the week. Please feel free to comment on the current text. -- R37. Language Accessibility 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 at the various levels specified by the WCAG 2.0 (perceivable, operable, understandable, and robust): specifically, the language MUST provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through a non-graphical UI. The user interface language MUST also be accessible to screen readers, allowing relevant sections of text and functionality to be accessed by non-visual means. Motivation: Compatibility with other standards, current development practice or industry best-practices, ease of use, accessibility. Rationale: To recommend a language, or a set of languages, that will allow authors to realize their designs, while at the same time remaining accessible to screen readers and similar assistive technologies. -- Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi David, On Tue, Aug 5, 2008 at 9:43 PM, David Poehlman [EMAIL PROTECTED] wrote: +1, not that Ihave a vote g chiming in here on this, You might pick this up, but one instance of language is written as langauge. fixed. for symetry, compactness and accuracy I suggest: replace assistive technologies such as screen readers with: screen readers and other assistive technologies Yep, much better! fixed. Thanks! -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
and transitions in the lifecycle of the instantiated widget. The transitions must have associated events which can be consumed by event handlers, such as scripts. Additionally the API must expose the current state.. That's much better. I've used your text but with some minor modifications and removed the word transition as it is too ambiguous (could be interpreted as visual transition, which I don't think is what we want here thought it would probably be valid enough). The text for the requirement is now: A conforming specification MUST define a set of states in the lifecycle of the instantiated widget. Changes in states MUST have associated events which can be consumed by event handlers, such as scripts. Additionally the API MUST expose the current state. A conforming specification MUST NOT require the widget user agent to send events to the widget immediately, and SHOULD allow the widget user agent to dispatch the events at its convenience. Is that ok? if the widget resource is connected to the network s/resource/instance fixed. (or any of its windows) s/windows/presentation contexts (Also add Accessibility to motivation here (and possibly in some other places, such as R37. It's the only unused design goal.) fixed, and added accessibility to r37, r34., r20, r13, r14. I'll probably add it to more before the next publish. operating system services s/system/environment Fixed. For example, when a news widget receives a news item about a particular company, it could tell a stock widget stock quotes widget to display any changes in that company's share price. Now I'm really surprised. The use case is perfectly reasonable, but what about addressability? Isn't it assumed elsewhere that only instances of the same widget can be addressed with the special scheme? Hmmm... I'm concerned that you are surprised. Have I have left some conceptual gaps in the spec? Do I need to explain things a bit more clearly in the introduction? Please let me know what you think I should do. I response to your question, it is not assumed that only instances of the same widget can be addressed with the widget scheme. Having said that, cross-widget communication is a bit gray ATM and I would personally like to see it removed from version 1.0. Having said that, I'm not sure how to proceed here. A conforming specification SHOULD specify a means that allows authors to open URLs How about IRIs? Changed it to IRIs. The declared interface may also be accessible to screen readers At least should, I suggest. Also see the rationale. Ok, changed it to should. persistently store user preferences for each instantiated widget. Instances are ephemeral by nature. Next run of the same widget resource yields another instantiated widget. Where's the persistence? Shouldn't the word instantated be omitted? Ok, I see what you mean. I dropped the word instantiated. Kind regards, Marcos [1] http://www.w3.org/TR/widgets-land/#differences -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
Hi Stuart, All, This email is a continuation of the discussion about the Widget URI scheme we've had in the past [1]. WebApps is trying to draft the final text for the Widget Requirements document regarding a URI scheme for widgets and we would again appreciate some input from the TAG. WebApps WG believes that we share similar (if not the same) objective to resolving the TAG's issue number 61 (URI Based Access to Packaged Items) [2]. Regarding URI based access to packaged items, the Widgets 1.0 Requirements document [3] contains the following Requirement: -- R6. Addressing Scheme A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. The addressing scheme MUST be able to address individual widget instances, while potentially allowing widgets to address each other. The addressing scheme MUST NOT expose the underlying file system to the instantiated widget and an instantiated widget MUST NOT be able to address resources outside the widget resource via the addressing scheme. The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed. Motivation: Ease of use, compatibility with other standards, current development practice or industry best-practices, security. Rationale: To allow resources to be resolved and normalized within DOM attributes. To make it easy for authors to address and load resources into their instantiated widgets, either declaratively or programmatically. For example, addressing a resource via an IRI (e.g. img src=images/bg.png'/ where the src attribute resolves to something akin to widget://myWidget/images/bg.png)). --- However, Krzysztof Maczyński has suggested we change the text above based on the following reasoning: On 2008/7/26 Krzysztof Maczyński [EMAIL PROTECTED] wrote: must not be able to address resources outside the widget resource via the addressing scheme Such ability may be useful (in some future version or even in this one), although I can see the concerns. But it seems harmless, for example, to use URNs (with semantics handled by widget user agent, such as accessing the default instance (forms in older versions of VB have those) or some operating environment motives and artifacts - these are outside the widget resource, right?). I presume there will be places where IRIs unconstrained by this addressing scheme can be used to allow such usage. Still, I think this must not cannot be enforced syntactically without disallowing relative IRI references (and I can see no reason for disallowing them). Another issue with this is that other instances of the same widget are themselves resources outside the widget resource (but not widget resources). Even though R5 currently only provides for addressing resources contained in the widget resource associated withj a given instance of the widget, I believe the goal is (or should be) to enable addressing the instances themselves as well. I would therefore suggest the wording given below for the entire paragraph. Also please clarify that addressing scheme means some recipe for minting URIs, not necessarily a URI scheme (which may or may not result from ongoing discussion as the best solution). -- A conforming specification must specify an addressing scheme (a new URI scheme or some prescribed use of an existing one) which must or should be used to address at runtime the individual resources within the widget resource in association with the current or another instance of the widget, as well as these instances themselves. This does not preclude allowing use of arbitrary IRI references in some contexts defined by a conforming specification. When the addressing scheme is used, the widget user agent must be required not to expose any other resources to the widget instance. For this purpose a conforming specification may require that accessing resources identified by IRIs using the addressing scheme which leave the allowed space described above must fail. If addressing resources outside the allowed set described above is possible with the addressing scheme, determining that this is the case for a given IRI reference should be easy for the author, at least for absolute IRI references. The addressing scheme should be one that web authors would feel comfortable using or are already accustomed to. Any thoughts or comments from WebApps members or the TAG are welcomed. [1] http://lists.w3.org/Archives/Public/www-tag/2008May/0121.html [2] http://www.w3.org/2001/tag/group/track/issues/61 [3] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing -- Marcos Caceres http://datadriven.com.au
Re: Widget Requirements: Updates vs security
Hi Thomas, On Thu, Aug 7, 2008 at 10:43 AM, Thomas Roessler [EMAIL PROTECTED] wrote: While I'm on it... I believe that we should add the following points to the automatic update requirement: - Conforming specifications should ensure that updates are authenticated. - Conforming specifications should provide a mechanism to protect against downgrade attacks using ancient versions of widgets. (Essentially, version information should be part of the Widget, signed, and evaluated upon updates.) - Conforming specifications should apply signature verification policies to updates that are consistent with those applied upon original installation of the widget. Ok, combining what we have already with your suggestions, the new text now reads: A conforming specification MUST specify a model to allow widget user agents to automatically check if a new version of a widget resource has become available online or from local storage. A conforming specification MUST recommend that an updated widget is downloaded only with the user's consent and that users be able to cancel or defer updates. An automatic update MUST preserve the identity of a widget, meaning that that preferences previously set by the user are retained after the update process. A conforming specification SHOULD recommend that, when possible, automatic updates be conducted over a secure communication channel. In addition, a conforming specification SHOULD specify a means for updates to be are authenticated. A conforming specification should also define a mechanism to protect against downgrade attacks using ancient versions of widgets. A conforming specification SHOULD specify that signature verification policies be applied to updates in a manner that is consistent with those applied upon original installation of the widget. I'm also wondering whether there is something to be said in the requirements document concerning the handling of possibly changing security declarations during updates. Need to think about this one a bit more; particularly in regards to use cases. For instance, in a new version of a widget, I might want to add support for file access and access to another domain, but retain the user's preset preferences. It would suck, as a developer, if I was not allowed to do that. -- Marcos Caceres http://datadriven.com.au
[Widgets] R21. Resource Declarations. Was RE: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, I'm wondering if you could help me understand R21. Resource Declarations, which was proposed in your feedback [1]: R21. Resource Declarations A conforming specification must specify a means for declaring that the instantiated widget will have an impact on sensitive device or network resources, which may impact device performance or the user experience. Motivation: Security, current development practice or industry best-practices. Rationale: To declare the resource requirements of the widget, allowing the widget user agent to respond accordingly by adjusting its resource policies and warning the end-user. Example of resource sensitive services that could require notification are automated operation involving network access or screen display, which can impact overall service cost and device battery life; or persistent storage requirements, which can affect device performance and reliability of the environment for other applications. I'm not sure I understand, from a developer's perspective, how I would declare resource use particularly because it seems so relative and subjective. For example, if I had created a widget and tested it on my super-phone I might think that it is not very resource demanding (this might be because the widget implementation running on my phone is very efficient and light weight). However, another widgets implementation might not be as efficient and hence it may use a lot of resources (but this is not the fault of the widget, it is the fault of the implementaiton). Another problem is that one phone might have limited resources by design (eg. limited RAM and storage) or because other applications are hogging resources. Maybe the requirement should be that the user agent should report to the user when a widget is hogging resources; however this seems more like something that would be best left to implementers. Can you maybe show us a usage scenario for what you have in mind for this requirement. How do you envision this would work? Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0298.html -- Marcos Caceres http://datadriven.com.au
Re: FW: Widgets i18n feedback
Hi Addison, i18n WG, Firstly, thank you again for taking the time to provide feedback. Your comments has substantially improved both the Requirements and the Packaging specification. Please see below details on how I executed the changes you recommended. For record keeping purposed as required by the disposition of comments, can you, or a representative from the i18n WG, please acknowledge that the WG is satisfied with the changes I have made to the Requirements document. On Fri, Aug 1, 2008 at 7:21 AM, Phillips, Addison [EMAIL PROTECTED] wrote: Hi, This note is on behalf of the I18N Core WG. The comments (below) that I sent to members of your WG previously have been endorsed by the I18N Core WG [1], with the following additional comments: 1. In my comment #3 below, we would strongly prefer the second suggested paragraph (MUST rather than SHOULD). Done, but with some modifications. Please see the inline comments below and feel free to make additional comments. 2. In my comment #15 below, we feel that it would be best if the charset parameter were required (MUST) and think that it should at least be strongly recommended (via the SHOULD keyword). Added a charset attribute with UTF-8 as the default charset. See below. Finally, (this comment is personal and not yet endorsed by I18N-WG), I note that the text in [2] still has a few flaws (this is Step 6), as it is confusing and doesn't really describe the lookup algorithm cleanly. There first two paragraphs are fine, but the remainder I would suggest changing to read (notes on changes follow //): -- The algorithm to determine the base URI and widget locale are as follows: 1. If the lang-priority-list is empty, or null, or i-default, or contains a single *, or is a sequence of items that only contain the * character, then terminate this algorithm and attempt to locate the configuration document. // deleted the 'default' keyword 2. For each range in the lang-priority-list: a. If this range is a single *, then terminate this algorithm and attempt to locate the configuration document. // dropped and this is the first subtag in the l-p-l b. Else if this range begins with the subtag '*', then skip this range and, skipping all the steps below, repeat this step 2. c. Else if this range contains a subtag *, remove the * and its preceding hyphen and continue. For example, en-*-US becomes en-US. // skip ranges that start with *, which are indeterminate d. Case-insensitively compare the range to each file name field for each file entry that is a folder in the widget resource. i. If they match: 1. Let widget locale be the name of the folder that matched the current range in lowercase form. 2. Let base URI be an absolute URI reference to this same folder. 3. Terminate this algorithm and attempt to locate the configuration document ii. Else, remove the last subtag of the range and repeat this step 2d. For example, if the range is currently en-US, make the range en. 3. If no match is made, attempt to locate the configuration document. For example, if the range is en-AU and a match is made on file entry whose name is en-au/config.xml, then base URI would be widget://f81d4fae-7dec-11d0-a765-00a0c91e6bf6/en-au, and the widget locale would be en-au. For example, if the language priority list is de-CH,fr-CH,it-CH and folders included de, fr-FR , and IT, then the folder de would be matched, then base URI would be widget://f81d4fae-7dec-11d0-a765-00a0c91e6bf6/deand the widget locale would be de. -- Ok, I used your text but made some tiny stylistic changes (but essentially they are identical). Thank you again for helping us with this section, it's solved a lot of problems. snip -Original Message- From: Phillips, Addison Sent: Thursday, July 10, 2008 2:02 PM To: [EMAIL PROTECTED] Cc: Marcos Caceres; Arthur Barstow; Felix Sasaki; [EMAIL PROTECTED] Subject: RE: Widgets i18n feedback Hi, My personal comments on the Widgets specs located at [1] follow. I have copied a few members of the WebApps WG on this message so they can see progress; these comments will be a Topic in our next teleconference, for consideration as the Internationalization WG's official comments. Comments follow. First, the requirements document: 1. In the introduction we see the (much better) comment: -- As argued by the Widget Landscape document, there is currently no formally standardized way to author, package, digitally sign and internationalize a widget resource for distribution and deployment on the Web. -- The widget-land document focuses on localization of widgets, which is important. This document should provide a solution to the above and this should be referred to as localization. Internationalization remains a problem because JavaScript has no locale facet
[widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
by widget developers and promote relevant industry best-practices, such as [MWBP] and [MWABP]. snipped r21as it is now in a different thread 3) Re R36. Open Default System Web Browser, a proposed modification (in red/underline below): A conforming specification SHOULD specify a means that allows authors to open URLs in a browsing contexts outside the widget engine. Motivation: Current development practice or industry best-practices. Rationale: To allow author to open a URL in the default system web browser. For example, in a news aggregator widget, to allow the end user to navigate to the source of a particular news item. ***Alternatively, if the widget has ability to directly present web content, a specific resource may exceed its capabilities, thus the user can be offered the option of opening the resource in the default system web browser, which may have greater capabilities. *** I rewrote your proposed text (and included it in the rationale): Alternatively, if the widget deems that a specific content may be better experienced outside the context of the widget user agent, the user can be offered the option of opening the resource in the default system web browser. 3) In 4.5 User Agents, add the requirements: Rxx. User-Agent Header A conforming specification must specify that the widget must identify itself in HTTP requests through the user-agent header, either as the complete header or as an extension to the default user-agent header provided by the runtime environment. Motivation: Current development practice or industry best-practices, interoperability. Rationale: To provide the ability for web servers to determine if it is possible to serve the widget, or to adapt to the capabilities or special requirements of the widget. For example, a widget may attempt to access a service which is not compatible with the widget, and rather than provide a possibly incorrect response (which could cause further issues with the widget), the web server can provide a specific error response noting the incompatibility. Ok, I added this requirement with a few minor changes. sniped CCPP requirement into a separate thread Rxx. Accept Header A conforming specification must specify that if a Profile header is not included in HTTP requests, the widget must include all supported MIME types for widget resources in the Accept header. Motivation: Current development practice or industry best-practices, interoperability. Rationale: To provide the ability for web servers to determine if it is possible to serve the widget, or to adapt to the capabilities or special requirements of the widget, using semantic methods based upon detailed capabilities information provided by the widget. Ok, added this requirement too with a few minor stylistic changes. Rxx. Default Use of Runtime Environment Configured Proxy A conforming specification must specify that by default, widget HTTP requests must be made through the proxy server (if any) configured for use in HTTP requests issued through the runtime environment or host device. Motivation: Security, current development practice or industry best-practices, Web and offline distribution, interoperability. Rationale: To ensure that widgets can be served in environments for which an HTTP proxy is required to be used, or be given value-added services available only through the HTTP proxy. For example, the runtime environment may be pre-configured to offer proxy services for all HTTP clients. Unless the widget has special requirements for use of a different proxy, the default proxy configuration should be used. I think the current requirement text basically says what your requirement says, so I kept the current text. I did, however, use your rationale text. Thanks again for taking the time to provide feedback and for the new requirements. I'm looking forward to discussing some of these issues MWBP has raised further. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-land/Overview.src.html -- Marcos Caceres http://datadriven.com.au
Re: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, MWBP WG, FYI, we discussed the MWBP input in last nights teleconf: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0417.html In summary, although I had included most of the requirements proposed by the MWBP WG in the Requirements document, the WebApps WG members overrode my decisions and chose not to include your recommended text into Requirements document. I have now removed the text I added earlier (below) from the Requirements document. The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms), (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side. If MWBP WG has concerns with the omission of any proposed requirement, we are happy to discuss anything further to reach consensus before we take the Requirements document to CR. Please note that WebApps is on an extremely tight schedule and we intend to move the Requirements to CR within three weeks; so if we don't hear back from MWBP we will assume that you are in agreement with WebApp's decisions. Having said that, I want to say that the feedback from the MWBP WG was extremely useful because it allowed the WebApps WG to more narrowly focus the architectural aspects of the Widgets 1.0 family of specifications. We want to continue coordinate with members of the MWBP WG on architectural decisions and guidance on best practices for widgets and mobile-based client side web applications. Kind regards, Marcos On Thu, Aug 14, 2008 at 7:45 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi Bryan, MWBP WG, On Fri, Aug 1, 2008 at 12:28 PM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Art, The MWBP WG consolidated comments are attached as a HTML document. General comments: Somewhere, perhaps in section 4.2, there should something about how resources (media etc) need to be compatible with the target device types, and that resource dependencies (screen, input device, network, processing, etc.) need to be spelled out. Widgets should be able to express these dependencies in a semantically useful way through a standardized schema and attribute ontologies/vocabularies such as W3C has been working on, e.g. the MWI DDWG's DDR Core Vocabulary, DDR Simple API, and the ongoing work of the UWA's Delivery Context Ontology. Although these are great technologies and I see the value that they could add to Widgets overall, the WebApps Working Group has yet to evaluate the suitability of these specification to Widgets. From our initial investigation, some of these technologies have the potential to significantly complicate widgets as a platform and I am personally concerned that they could become a barrier to the adoption of Widgets. Personally, I would like to see the progressive inclusion of the technologies you mention as they become more prevalent in the mobile space and as developers start asking for them. I am also of the opinion that our primary focus right now (version 1.0 of Widgets) should be on specifying packaging and the core APIs. The specific text below related to expression of user agent characteristics (via the User Agent, Accept, and Profile headers in HTTP requests) is important in the meantime as a standardized way to at least disclose web application (and host device) capabilities, but longer term a way of expressing dependencies is important also. I agree conceptually with what you are saying, though I have concerns about the Profile headers side of things. Re R16 Visual Rendering Dimensions: the text states that there must be a way of declaring initial dimensions in pixels, which is potentially at odds with the limited canvas available on many mobile devices. Resource/capability expression as described above would at least ensure the dimensions were defined in a standardized way. The requirement reads A conforming specification SHOULD specify a means for an author to declare the initial visual dimensions for an instantiated widget in a way that is device independent (e.g. via CSS pixels). The requirement does not actually state that it must be be pixels (CSS pixels are an example), just that some means SHOULD be provided to declare the dimensions. Other that described in R28. Network State Change Events, is there something specific that can be said re requirements supporting widgets that are intermittently connected? The rationale now reads: To allow authors to programmatically capture when the widget user agent has acquired or lost a network connection, particularly for cases when the device intermittently loses and regains the network connection. Suggestions for specific text: 1) As design goals, a new section 3.1 can specifically introduce the mobile web best practices that W3C has developed / is developing. Here is some proposed text: 3.1
Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)
of PKCS from the requirement. It's support is implied by not mandated. Do we really need to support it? and if we do, lets just add support in the DigSig spec and not mention it here. Please let me know if you agree or disagree. The Key Usage Extension requirement is a good catch. I'd like to understand the motivation for the inclusion of revocation information requirement better. I think that it's a good idea to mandate widget engines to consult CRLs. However, I wonder if packaging these into the widget itself won't cause a significant likelihood of stale information, at least in Web-based deployments. [MP] In a lot of cases stale information could be avoided by implementing the necessary server side logic and processing, however, you are right, including revocation information in the package will lead to cases where the information is stale and the widget client will need to fetch new information. The motivation behind this requirement is to be able to reduce load on revocation information servers based on experience with mobile applications. Strain on servers seems like an implementation detail. Seems to me that if widget publishers are having problems with their servers, and they are serious about their business, then they should upgrade their servers to handle the verification load. Though I can understand that taking some load off servers would be a good thing but it seems to add more complexity to the digsig model... Is that a fair call? -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] R21. Resource Declarations. Was RE: Request for Comments on Widgets 1.0 Requirements Last Call WD
the technical solutions that are being proposed don't address. I think a better approach to all the problems you list would be to allow such declarations to be managed independently of the widget package (and hence the author), so that device capability information can be dynamically updated remotely as technology progresses or regresses (e.g. in a last ditch effort to curve global warming, a global agreement is reached that requires devices to be more environmentally friendly at the expense of performance and battery life... etc.). Such a system could be managed by an external trusted community, such as the community that contributes to, and gets widgets from, a widget download website. The technological infrastructure needed to develop such a thing is beyond the scope of Widgets 1.0 (but that's not to say that it should not be part of any Widgets 2.0 effort). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] CCPP in widgets, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, On Thu, Sep 4, 2008 at 12:18 AM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Marcos, Responding a little late (vacations etc), The CCPP use I've proposed is fairly simple, ala the delivery of a link to a capabilities document that is hosted on a web server, and semantically useful. This is what mobile devices have done for years via the OMA UAProf (using the x-wap-profile header over-the-air, which is sometimes mapped to the profile header in WAP gateways), and while not universal and not without limitations (some of which we are addressing via OMA DPE, W3C MWI/DDWG, and W3C UWA), it represents the only semantically useful way to disclose detailed application characteristics (at least widely deployed and used). The problem, as the working group sees it, is the reliance on RDF (when considering CCPPexchange, which, at the last F2F the group took objection to because that spec is a Note and hence non-normative): RDF puts an unnecessarily heavy burden on anyone on the receiving end of the technology, particularly for something that, as you state, is supposed to be simple. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, On Thu, Sep 4, 2008 at 6:42 AM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Marcos, I was starting to respond and thank you for the inclusion in the previous email when I saw this... having been out for vacation etc I did not get a chance to respond earlier. Yeah... as you know, I did include the requirements in the Requirements doc, but I was overruled by the working group and the consensus was reached to remove them. I would like the opportunity to discuss these in detail and support the rationale on the Widgets call. I don't understand the justification for rejection you have described. Overall the requirements represent the core (a limited set) of some pragmatic considerations that will affect the success of widget frameworks in real-world deployments, especially in the mobile device context. As you stated: The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms), (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side. (a) Is unclear (which specs are you talking about?). The Widget Requirements spec is the one being commented on, and it is giving direction to conforming specification writers (presumably in W3C and externally). Several of the proposed additions were written in normative terms and meant to be so. At the top of the Widget Requirements document, I list the specs that make up the Widgets 1.0: Family of Specifications. Those are the specifications that, possibly in conjunction with other W3C or external standards, will collectively address the requirements. During our August 14 teleconf [1], the Working Group reached consensus that we could not address the requirements within the specs we are producing or we disagreed with the requirement. Please refer to the teleconf minutes [1]. (b) In which cases were they overly prescriptive. This seems to me to be a value judgment based upon some criteria. The criteria I use is whether there will be significant negative effects on usability, interoperability, or efficiency if the requirements are not supported. Especially in the mobile case, the normative requirements I proposed can be supported in one or more of those terms. Again, it's not that we disagree with the requirements. It's just that some of them where prescriptive of technologies that the working group did not believe actually addressed the requirement (eg. CC/PP, etc.) (c) Re complexity, little of value comes free. But overall I don't think any of the proposed normative requirements could reasonably be called complex. I am willing to explain why if given the opportunity. We welcome all feedback and I'm personally happy to continue discussing any issues further. However, please be mindful that the working group is on a very tight deadline for these specifications (October's TPAC) and we would like to get MWBP's working group's approval or formal objections (if any) ASAP so we can move the Requirements forward along the publication track. If possible, we would really appriciate a formal response on behalf of MWBP by the end of next week. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0417.html -- Marcos Caceres http://datadriven.com.au
Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
and DSA with key lengths of at least 2048 bits (see NIST Recommendation). Motivation: Security Rationale: To be in-line with current security recommendations and provide longevity of the system security. In some use cases it may be desirable to use key lengths of less than 2048 bits, e.g. where the impact on performance outweighs the additional security afforded. RXX. Key Usage Extension A conforming specification MUST specify the expected use of valid key usage extensions and when present (in end entity certs) MUST specify that implementations verify that the extension has the digitalSignature bit set. A conforming specification MUST specify that implementations recognize the extended key usage extension and when present (in end entity certs) verify that the extension contains the id-kp-codeSigning object identifier. A conforming specification MAY also define a new OID specifically for widget signing, and specify that implementations verify that the extended key usage extension in the end entity cert contains this new OID. Rationale: To maintain compliance to RFC 3280 (experience suggests that if this is not explicitly required then the RFC 3280 is not followed when it comes to key extension usage). Compliance ensures that only certificates intended to be used (issued for) code signing can be used to sign widget resources. Comments: Using the extended key usage extension id-kp-codeSigning would in theory allow the same end entity certificate to be used to sign any executables including widgets, Java applets and native executables. However, it should be possible to restrict the use of a particular end entity certificate so that it can only be used to sign certain a certain type (or types) of executables by associating a usage restriction with the root certificate to which the end entity certificate is chained. RXX. Inclusion of Revocation Information A conforming specification SHOULD specify a means of packaging up-to-date revocation information with digital signature and associated certificate chain (e.g. a CRL or OCSP response stating that certificate has not been revoked). In addition, a conforming specification SHOULD specify the behaviour in the case that the revocation information is not included or not complete. A conforming specification SHOULD specify that if the revocation information is present the widget processing environment MUST attempt to verify the revocation information. A conforming specification SHOULD specify the behaviour if revocation information is out of date or otherwise invalid. In addition, the mechanism specified SHALL not require the widget resource to be re-signed to include new revocation information. Rationale: To provide up-to-date revocation information, when it is needed by the widget engine, without requiring a query to an online CRL or OSCP server from each device. This is a lot more efficient and eases the load on CRL or OSCP servers. END OF DOCUMENT Many thanks, David. David Rogers OMTP Director of External Relations m: +44 (0) 7771 838197 [EMAIL PROTECTED] skype: dg.rogers linkedIn: http://www.linkedin.com/in/davidrogersuk OMTP Ltd. Marble Arch Tower 55 Bryanston Street London W1H 7AJ www.omtp.org P Please consider the environment – don't print this mail unless you really need to... -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements - Editor's Draft 15 August 2008
upgraded? Open issue. My preference is that, yes, they all get updated. However, we will deal with that in the spec. R43. Default Security Policy To make the default state of a widget as benign as possible. change state = behavior ? Sounds good. Changed. This is a meta note listing most/each of the 'Motivation' items, most of which end in periods, most of which begin with a capital letter and most of which seem to almost be sentences, however they have 'and' or 'or' in non sentence positions. I'd suggest that these all be changed to if possible to try and only use one and/or per sentence, always before the last listed element, and to remove capitalization from non leading words unless it's strictly required. Oh, and periods should be used consistently :) 'and' before last item: snip All fixed... Thanks again! -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
question, it is not assumed that only instances of the same widget can be addressed with the widget scheme. Having said that, cross-widget communication is a bit gray ATM and I would personally like to see it removed from version 1.0. Having said that, I'm not sure how to proceed here. WG discussion, I guess. If it happens, please input my above brainthunder (item in brainstorming ;-)). Limited discussion about this happened at the last f2f but no real progress was made. The declared interface may also be accessible to screen readers At least should, I suggest. Also see the rationale. Ok, changed it to should. I wrote at least. But since then I've reconsidered, based on an interpretation of should I've come across and assimilated. Shoulds are for things without which the product is still usable, albeit maybe with a limited functionality. Accessibility to screen readers is indispensable sometimes. As failing to meet this requirement would effectively block some users, I request that it be a must. The WAI community also raised similar concerns. It is now a MUST. However, I personally think that it is romantic to say that HTML on its own can truly meet this requirement (though adding ARIA into the mix seems to get us closer). Marcos, in my opinion you're an editor very responsive to comments, including critical ones. You put much effort into maximizing the quality of the produced specification, which I've come to appreciate even more as I shared some of it writing my 3 detailed reviews with fragments of suggested text. As a Web user, one of the many, I feel incited to express gratitude for your work. Thank you. Thank you for your kind words and for taking the time to provide us with such detailed feedback. Your comments have been challenging for me to answer and I hope that the changes that I have made to the spec are to your satisfaction. To be sure, your comments have substantially improved the quality of this specification and possibly the direction the WG will take with this work. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] feature element strawman
Hi All,
Here is a summary of the new feature element (and some associated
APIs) that we added to the widget Configuration Document at the Turin
F2F (replaces the requires element).
When combined with digital signatures, the feature element acts as a
secure device capability discovery mechanism and a API binding
mechanism (in effect, it hopefully simplifies what DCCI tries to
achieve without all the burden of ontologies and treating everything
as DOM nodes, etc).
widget ...
access
feature [required=yes/no]
id=uri
name=localname/
/access
/widget
The attributes are as follows:
id:
the URI that identifies the feature (eg. urn:org.w3.www.someAPI or
http://www.w3.org/api/device/camera/;).
required:
if the feature is mandatory for this widget to work properly. If a
feature is not available, the widget will not run.
name:
a developer friendly shorthand that a developer can use to call up
the API in JavaScript (eg. getFeature(Phone GPS)). The intent is to
hide nasty URIs from developers and giving them some simple syntactic
sugar instead. For example:
widget ...
access
feature id=http://w3.org/api/device/camera;
name=camera/
/access
/widget
Then, at runtime, we introduce the following API:
Widget.features; // a list of the declared features that were available.
Widget.getFeature(name of feature); //the name of a feature as
declared in the feature element
Usage example:
In the start file:
!doctype html
script
if(Widget.getFeature(camera)){
camera = Widget.getFeature(camera);
camera.powerOn(...some call back...);
camera.takePicture(...some other call back...);
}
/script
The feature element allows for fallback, so that if one feature is
not available, another may be used in its place. Eg. load proprietary
API for camera and if it fails, load the W3C one:
widget name=sportPhotoWidget
access
feature id=http://cannon.com/api/device/camera?shutterspeed=1000;
name=Cannon camera
feature id=http://w3.org/api/device/camera;
name=generic camera required=true/
/feature
/access
/widget
With this proposal, we make a leap of faith in that we want future
APIs standardized by the W3C to be identifiable via a URI (the same
leap of faith that seems to DCCI make). I guess we need to encourage
the TAG to support this practice and hope that we can convince the
GeoLocation guys to add a URI to their spec.
thoughts, comments, etc
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
[widgets] i18n span element VS unicode RLM/LRM
Hi, i18n-WG. In recent feedback we received from Addison Phillips regarding the Widgets 1.0: Packaging specification, he suggested that WebApps should add a span-like element to our Widget Configuration Document format (so to allow bidi text to be declared). At our last F2F, WebApps discussed the proposition and we were left wondering if we can use unicode's RLM/LRM characters instead of a span-like element? Can i18n please advise us on this? Not having the span-like element significantly simplifies our processing model. We don't want to sacrifice i18n for the sake of simplicity, so we really need your guidance again on how to move forward. Having read Internationalization Best Practices: Handling Right-to-left Scripts in XHTML and HTML Content, we are aware that there are problems with text editors ATM, but we are hoping the tools will improve as Unicode support becomes more common place (or is that wishful thinking?). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Great! Thank you David, and thanks to OMTP members for this important contribution. I personally look forward to our continued collaboration to take the Widget specs to REC :) Kind regards, Marcos On Wed, Sep 10, 2008 at 7:08 PM, David Rogers [EMAIL PROTECTED] wrote: Hi Marcos, On behalf of OMTP, I'd like to thank you for your hard work integrating the OMTP input to the requirements spec. We're happy with the changes in [1]. Thanks, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcos Caceres Sent: 05 September 2008 14:30 To: David Rogers; Nick Allott; Priestley, Mark, VF-Group; Paddy Byers Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2) Hi All, I've now integrated the OMTP requirements into the Req spec. OMTP crew, I'm made lots of edits (and dropped some of your requirements with Mark's permission) so please check to see that your intent is still conveyed (and that I haven't introduced any new typos, etc.). Apologies to those who are still waiting for me to respond to your comments, I'm going as fast as I can and will do my best to address everyone's comments within the next week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Fri, Aug 1, 2008 at 12:30 PM, David Rogers [EMAIL PROTECTED] wrote: Dear Art, Marcos and all, Please find attached the OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call. I've extracted the text of the input below. Please note this is the first of two sets of input. This first input contains comments to existing requirements and proposals for new requirements. The second document contains more general comments, applicable to the Widget Requirements and also the Packaging and Configuration work. 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 document forms the input from BONDI relating to the security aspects of the W3C Widgets: 1.0 Requirements found at http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/. The document is divided into two parts; the first part details proposed changes to existing W3C requirements, the second part proposes new requirements that for inclusion. Part I - Changes to Existing Requirements Proposed By BONDI R11. Digital Signature We suggest the following re-wording of the existing requirement so that it reads: A conforming specification MUST specify a means to verify the authenticity and integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification. A conforming specification MUST provide this capability by specifying a processing model for generating and verifying a digital signature associated to a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the recommended digital signature format SHALL support the ability to include a certificate chain with a digital signature to enable the receiving device to build a certificate chain from the end entity certificate used to generate the signature to a locally stored root certificate. In addition, the recommended digital signature format SHOULD support the ability for a widget resource to be signed using multiple end entity keys (i.e. it SHOULD be possible to include multiple signatures and associated certificate chains). The proposed changes attempt to tighten and clarify the use of digital signatures and certificate chains. In addition we suggest that the following text should be added to the existing requirement: A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures
[widgets] update death of the etag attr
Hi All, I've dropped the etag attribute from the update element in the Widget Packaging spec as I deemed it too difficult to use in practice (and mostly redundant). It is also unnecessary as updates will be handled through Update Description Documents as defined in the Updates spec (and not by pointing to widget packages on the Web). I will try to have the Update spec ready for FPWD by the end of today. Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widget Icon behaviour...
Hi Jochen, On Wed, Sep 17, 2008 at 12:02 PM, Jochen Cichon [EMAIL PROTECTED] wrote: Hi, short question on the icons, inside the config.xml. (I know, that part is not yet written) It is possible to store more than one icon, but which icon is used? My thought was to have several icons in different sizes, or even an SVG icon (which is not a must for the widget UserAgent). Currently I'm unsure which icon is used, because the widget UA does understand gif, png and jpeg (maybe others). Given the following example (e.g. small is 32x32, large is 64x64, huge is 128x128pixel. And svg is ... scaleable ;) widget .. icon src=icon.svg/ icon src=small_icon.png/ icon src=small_icon.gif/ icon src=large_icon.jpg/ icon src=huge_icon.jpg/ /widget So for my point of view, the UA will need to find the size of an icon by reading the header or even the full image, or in the case of an svg say that it will scale to any resolution. This is correct. But then the question which icon will have precedence? Depends on the rendering context and media type. Please see: http://dev.w3.org/2006/waf/widgets/#icons http://dev.w3.org/2006/waf/widgets/#displaying We are working on this text at the moment, so if it's still a bit vague let us know and we will try to clarify it. Also from my point of view, the first icon will be used. So in the example above the PNG may look better than the GIF. (example) Again, please see the links above. -- Marcos Caceres http://datadriven.com.au
Re: [XHR] Some comments on charset in the Content-Type header
On Fri, Sep 19, 2008 at 3:37 PM, Michael(tm) Smith [EMAIL PROTECTED] wrote: Boris Zbarsky [EMAIL PROTECTED], 2008-09-19 09:35 -0400: Anne van Kesteren wrote: http://dev.w3.org/2006/webapi/XMLHttpRequest/#send Oh, right. I keep forgetting that the spec actually on the main W3C site has no bearing on reality... Is there a good reason it's there at all? :( It's intended in part to be a way to keep all our law-abiding citizen readers in the general public informed about what progress if any the group is making on the spec. Those of us who are actually members of the Mongols, Boozefighters, Bandidos, or other MCs should always follow the editor's draft instead. This does bring up the wider issue of the importance of Editor's drafts. I think more emphasis should be put on the standard W3C template for WDs to point to an editor's draft (if one is publicaly available). Most specs get grossly outdated within a few days of publication on the TR page. -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
specified format (gzip and deflate are most common, I think) and any granularity. Ok. I see your point. However, I'm not sure what I can do as vendors won't budge on this issue for now. At the moment, ZIP serves the purpose for widgets. But as they become more popular, the limitations with Zip will quickly be exposed. Zip will either have to become more like MIME or we will have to migrate over to MIME... we will seriously need to watch the evolution of Widgets and the market in regards to this. In your example, the MIME type is not the correct so processing would fail for that resource (unless sniffing takes place on the SVG file or it actually is an audio clip). Well, maybe that will tell you something about the Web science (cool new term, isn't it? ;-)) way of thinking. When I wrote my example it was obvious to me that x.svg actually contanined an audio clip. Were I to include an invalid example, I'd most probably warn of it. My point in many of our arguments is that graceful catering for invalid cases can be a noble goal only as long as it doesn't blow up in the face of people who do the right thing instead. (Note: the example wasn't 100% the right thing because of an uncool URI, as I mentioned, but certainly it was valid. I can legitimately put an audio/basic resource at any http: URI under my control. And expect the rest wishing to interact to obey Web architectural rules because I obeyed them for my part.) agreed. Understood. Like I said, we only need sniffing for when resources are received from sources other than the web. When a WUA is getting a widget from the web, it should follow standard MIME style processing. Very well, glad to read it stated explicitly. How is that in scope then? This would be the first W3C spec going to extra lengths to ensure interoperability outside the Web. You may claim it serves the Web to have broader interoperability and I do sympathize with this but I think for W3C to maintain its well established and clearly perceived position there cannot be any MUSTs on what happens elsewhere, at most SHOULDs. Only one correction though, if I may: MIME is used in some offline contexts and should be respected there as well. On the other hand, although it's bad practice, a WUA might come across a resource without a MIME type on the Web (and on the Internet more generally). It's perfectly legal not to mention at all sniffing, which is allowed in such cases (and only then, on the Internet at least), indeed all existing specs I know leave this entirely to implementors, but I bet you wouldn't like to miss this opportunity. We don't want to be accused on not having covered the case that was obviously going to come up in practice (dealing with a resource without a MIME). For me, it's not a big deal to specify it... even it the spec says treat it as invalid. I'll restate one of my questions. Could you list in one place the technologies with existing standards you considered for R26? There seems to be no record in the list archives. I can't list them off the top of my head, but pleas see the [widgets] Widgets URI scheme thread here: http://lists.w3.org/Archives/Public/www-tag/2008May/subject.html And see also: http://lists.w3.org/Archives/Public/www-tag/2008Aug/0121.html We basically evaluated all the different packaging formats (and URI schemes) that people suggested. Admittedly it was very few because we knew it either had to be MIME or Zip (the current de facto standard). However, I personally think that it is romantic to say that HTML on its own can truly meet this requirement Why not? (X)HTML is designed with accessibility in mind, applies the tenet of separation of concerns (semantics from presentation), as a result it's not only media independent but even presentation agnostic (meaning that you could well have (X)HTML documents not intended for being rendered to users at all, e.g. as a back-end archiving format or intermediate step in a processing pipeline). Of course it gets horribly misused by many. And the success of providing a reasonably good toolset specifically for styling (CSS) has so far led to quite limited improvements of authors' practices in architectural terms (mostly because of an overwhelming number of bugs in browsers and authoring tools, but that's a subject for another conversation). Ok; yes, simple HTML pages can be authored to be accessible. More complex Web applications, like Google Reader, need a little more (like ARIA). So what I meant was the HTML has to be enhanced in order to meet the accessibility requirements that users have come to expect from today's Web. [1] http://www.gcn.com/blogs/tech/41547.html -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
On Tue, Sep 23, 2008 at 4:02 PM, timeless [EMAIL PROTECTED] wrote: 2008/9/22 Marcos Caceres [EMAIL PROTECTED]: Ok. I see your point. However, I'm not sure what I can do as vendors won't budge on this issue for now. At the moment, ZIP serves the purpose for widgets. But as they become more popular, the limitations with Zip will quickly be exposed. Zip will either have to become more like MIME or we will have to migrate over to MIME... we will seriously need to watch the evolution of Widgets and the market in regards to this. note that BeOS w/ its BeFS used mime types for files and it supported stashing mime types into zip files, I don't remember how, but I'm fairly certain it did it. There is lots of ways of putting the mimetype into a zip file. For example, one could use the comment block, or do what OCF does (include a file called MIMETYPE as the first file). -- Marcos Caceres http://datadriven.com.au
Re: typo in Widgets 1.0: Requirements (2nd Last Call),Editor's Draft 22 September 2008
Tha On Thu, Sep 25, 2008 at 5:41 PM, Eric [EMAIL PROTECTED] wrote: Please fix the introduction : more geneTic user agent (eg. a Web browser) should be geneRic Fixed. Thanks! Marcos Caceres http://datadriven.com.au
[widgets] Preferences API
Hi All, I think we should dump the Widgets preferences API in favor of HTML5 DOM's storage API. Basically, preferences API basically replicates what DOM Storage already defines. Also, DOM storage is already implemented across three or four browsers and we can assume the specification to be fairly stable (or hopefully it will be by the time we get to CR). Dumping the preferences API will also avoid problems in the future as HTML5 becomes prevalent in the market. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Preferences API
On Tue, Sep 30, 2008 at 12:19 PM, Arve Bersvendsen [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008 01:35:42 +0200, Marcos Caceres [EMAIL PROTECTED] wrote: Hi All, I think we should dump the Widgets preferences API in favor of HTML5 DOM's storage API. Basically, preferences API basically replicates what DOM Storage already defines. Also, DOM storage is already implemented across three or four browsers and we can assume the specification to be fairly stable (or hopefully it will be by the time we get to CR). Dumping the preferences API will also avoid problems in the future as HTML5 becomes prevalent in the market. While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? As Jonas said, we would just mandate that implementations implement just that one part of HTML5. Or, we just rip that part of HTML5 and put it in our spec and make sure we keep them synced. Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? I also agree with Jonas that if it's good for widgets, it's probably good for HTML5 as a whole. For V1 of widgets, I think that HTML5's storage meets r26 [1]. But if new requirements arise (such as data encryption) we should work with the HTML-WG on that. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/#r26.- -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Preferences API
On Tue, Sep 30, 2008 at 5:36 PM, Arve Bersvendsen [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008 18:28:59 +0200, Marcos Caceres [EMAIL PROTECTED] wrote: While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? As Jonas said, we would just mandate that implementations implement just that one part of HTML5. Or, we just rip that part of HTML5 and put it in our spec and make sure we keep them synced. If we are to do one of these, I'd very much prefer not to have to keep it continously updated until 2022. Agreed. If the Working Group feels comfortable with citing HTML5 for this feature, I think we should. Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? I also agree with Jonas that if it's good for widgets, it's probably good for HTML5 as a whole. For V1 of widgets, I think that HTML5's storage meets r26 [1]. But if new requirements arise (such as data encryption) we should work with the HTML-WG on that. Note that encryption, which was my example here, may be an implementation detail. I was just trying to say something about the requirement for HTML5 and Widgets might be different. Understood. Appologies, I didn't mean to imply you meant it as an actual feature request. Having said that, the requirements for v1 in regards to this feature are clearly captured in the requirements doc. As we now have consensus within the working group regarding the requirements, I don't foresee them changing for V1. If we need to fork for V2, that should hopefully be ok. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Some comments on Widgets 1.0: Packaging and Configuration
Hi Dom, On Tue, Sep 16, 2008 at 10:20 AM, Dominique Hazael-Massieux [EMAIL PROTECTED] wrote: As I started looking at the testability of the Widgets 1.0: Packaging and Configuration specification, I spotted a few things that I thought I would mention (based on the CVS editors's draft [1]): * the relax NG schema doesn't include a definition for the update and requires elements; it doesn't include the declaration of the mode attribute on the root element, of the img attribute on the author element, of the width, height and alt attribute on the icon element, of the files attribute on the access element As you know, the schema has now been updated (but will soon be out of date again). However, I don't want to waste David's time continuously updating the schema until the text in the spec has stabilized. * 6.10 When the access element is absent, a widget user agent must deny access to networked resources and to plugins, and presumably to the file system as well; instead of separate boolean attributes, what about having these as a single token-based attribute (e.g. access=network plugins) You raise a good point. We are considering dumping the access element and using feature for everything. So, we would have something like: widget ... feature id=http://www.w3.org/widgets/network; / feature id=http://www.w3.org/widgets/plugins; / /widget We will be debating this model over the next few weeks. * some of the green notes highlight interoperability problems - this sounds like material for conformance requirements rather than just notes. We have debated at length in the past about whether these notes should be normative or not (I'm sorry, I can't provide you with a reference/pointer right now), we reached a resolution that we would leave them as notes for now. If upon building a reference implementation (or the test suite) we find that these in fact are going to cause interop issues, then we can easily change them. * Author requirements probably ought to called Authoring requirements since you're not trying to define conformance for authors but for what they author You are probably right, but we are keeping this consistent with HTML5 (which currently uses Author requirements). * there seems to be well-known filenames that have special semantics attached in the widgets specs (at least config.xml, signature.xml, the locale directories); the list of reserved filenames sounds like something that should be explicitly documented in the packaging spec; in particular, it should probably be recommended not to use 2 and 3 letters names for directories at the root of the archive (trivia: which in the followings is not a language code: cat, bin, bak, iii, inc, lol, map, oss, run, sux, tel?) I have added a section in the spec called Reserved filenames and created a table that lists what names are reserved and for what purpose. I also added a note warning authors about the use of 2 to 3 letter file names. * If the access element is used, a full URI must be given - I don't think the notion of full URI is defined anywhere Yep. I need to go through the whole spec and fix up all the URI related stuff. This is a big job, which I am currently working on. * the references section don't distinguish normative from informative references; fixed. Prefixed References with the word Normative. Will add an Informative References section later if one is needed. * there seems to be a normative reference to HTML 5 in Rules for Identifying the Content Type of a Start File, but HTML 5 is not in the list of references; also, having a normative dependency on HTML5 means the spec won't be able to go to REC until HTML5 does Understood. We will look at ways of minimizing our dependencies on HTML5. However, I personally don't see it as a problem if this spec sits I'm sorry these comments are a bit randomish, but I thought I would send them while I looked at the spec. No, that's great! thank you! -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
[Widgets] URI Scheme revisited.... again
Hi All, I think, for V1, that we should drop the authority part of the widget URI scheme and leave it as an implementation detail (but add a note saying that we might add a scheme in V2). I propose this because we don't currently have an API or security/interaction model for cross-widget communication and I don't think we will get one by the end of the year (not from me, anyway... and I haven't seen any other member put forward any real viable solution to this problem). Another reason is that it simplifies the widget URI scheme, but still allows us to expand on it later (v2). My proposal is: widget-uri = widget:// path-absolute [# fragment] (query strings are not supported (ignored) in v1) In other words, DOM nodes would be resolved to: widget:///someFolder/SomeFile.ext#someFragment I'm also not convinced that uniquely identifying the widget should be part of the authority (if we do decide to use it, would it b more appropriate to hijack the :port?). For example, widget://:a34af23bh23/myFile.png Marcos -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, On Wed, Oct 8, 2008 at 4:28 PM, Mark Baker [EMAIL PROTECTED] wrote: Marcos - IIRC, there was little or no support for a widget URI scheme in the discussion on www-tag. Why are you continuing to move ahead with it? Sorry Mark, I'm afraid that your recollection on this issue is wrong. Firstly, I was not aware that the TAG dictated what Web Apps works on. Secondly, the TAG is interested in solving this problem as much as we are [1]. Thirdly, TAG members have requested time at TPAC to meet with Web Apps to allow us to move forward on this issue (if there was little support, then why do they want to meet with us? [2]). Fourthly, we continue to push for a URI scheme because we can't resolve DOM nodes in widgets to nothing (and we see the use of the file:// scheme as bad (and not standardized) and http://; as too complex for V1). There is no way for us to ignore the URI issue, so we need help in resolving it. Asking us to stop working on this is not an option. However, if you can help us or point us in the right direction then please do so! Note that you'll still have to get this past IANA who maintains the registry. IANA uses a process specified in RFC 4395 which says; The use and deployment of new URI schemes in the Internet infrastructure is costly; some parts of URI processing may be scheme-dependent, and deployed software already processes URIs of well-known schemes. Introducing a new URI scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [11]. URI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded registration of new schemes is harmful. New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. -- http://tools.ietf.org/html/rfc4395#section-2.1 We have evaluated other options and none seem suitable. However, I we are always open to suggestions of schemes to investigate (so long as they are in line with our packaging requirements; hence, no MIME formats for version 1.0 please!). The requirement for the URI scheme is as follows: R6. Addressing Scheme A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. The addressing scheme MUST be able to address individual widget instances, while potentially allowing widgets to address each other. The addressing scheme MUST NOT expose the underlying file system (if any) to the instantiated widget and an instantiated widget MUST NOT be able to address resources outside the widget resource via the addressing scheme. The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed. Motivation: Ease of use, compatibility with other standards, current development practice or industry best-practice, and security. Rationale: To allow resources to be resolved and normalized within DOM attributes. To make it easy for authors to address and load resources into their instantiated widgets, either declaratively or programmatically. For example, addressing a resource via an IRI reference (e.g. img src=images/bg.png'/ where the src attribute resolves to something akin to widget://myWidget/images/bg.png). To disable access that could lead to potentially unsafe manipulation by widget instances to the underlying file system (if any) or other resources which are not instances of the same widget or resources contained in the widget resource used to create the current set of widget instances. Kind regards, Marcos [1] http://www.w3.org/2001/tag/group/track/issues/61 [2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda -- Marcos Caceres http://datadriven.com.au
Re: [widgets] i18n span element VS unicode RLM/LRM
Hi Felix (and i18n Core),
During our last WAF teleconf, WebApps decided to adopt your
suggestions (below). I've been attempting to integrate your
suggestions into the Widget Packaging spec [1]. Below I summarize what
draft text I have added thus far. I would really appreciate any
feedback if you think I've gone about specifying what you intended
correctly.
On Thu, Sep 11, 2008 at 1:32 AM, Felix Sasaki [EMAIL PROTECTED] wrote:
Marcos Caceres wrote:
Hi, i18n-WG.
In recent feedback we received from Addison Phillips regarding the
Widgets 1.0: Packaging specification, he suggested that WebApps should
add a span-like element to our Widget Configuration Document format
(so to allow bidi text to be declared).
I think such an element would only be necessary within these elements: name,
description, author, license. It seems that only these elements may contain
human readable text.
Agreed. More on this below.
snip
I personally would recommend you to use the its:span element in the ITS
namespace. The element is defined at
http://www.w3.org/TR/2007/REC-its-20070403/#span
This element gives you the dir attribute and various other attributes
which are useful for esp. Widgets localization. See
http://www.w3.org/TR/2007/REC-its-20070403/#att.local.no-ns.attributes
See also the related Best Practice to define such an element for XML
vocabularies at
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/#DevSpan
To keep simplicity for Widgets 1.0, you could say in your conformance
description that a Widgets processor has various options to deal with the
its:span element (or more in general: the ITS namespace) and its
attributes: ignore them or process them.
Ok, in the Widget User Agent conformance section I've added the
following text for your consideration:
A widget user agent MAY support the Internationalized Tag Set's
its:span element and the its:dir attribute [ITS]. Support of any
other ITS elements and attributes is NOT REQUIRED. Although this
specification specifies the elements of the configuration document in
which its:span and its:dir can be used (below), it does not define
how they are to be interpreted and processed by a widget user agent.
If a widget user agent implements its:span and its:dir, then they
MUST do so in conformance to the processing rules defined by the ITS
specification.
Then I've added the following subsection to the Configuration Document
section...
== Indicating text directionality and its:span ==
Although it is optional for a widget user agent to implement [ITS],
authors are may use the its:span element to indicate the
directionality of arbitrary content. Directionality is indicated by
using the its:dir attribute in conjunction with the its:span
element. The its:dir accepts one of the following values, as defined
in [ITS]:
dir=ltr - left to right text
dir=rtl - right to left text
dir=lro - left-to-right override
dir=rlo - right-to-left override
For example,
widget
xmlns=http://www.w3.org/ns/widgets;
xmlns:its=http://www.w3.org/2005/11/its;
nameYay for the its:span dir=rtlمتعة الأسماك!/its:span
Widget/name
/widget
The its:span element can be only be used as a child of the following
elements of the configuration document:
* name
* description
* author
* license
If you do not want to add markup from a specific namespace, you could or
should IMO add extensibility points for people who need such markup. That
is, change in the schema something like
description = element description {
xmllang.att?,
text
}
to
description = element description {
xmllang.att?,
any
}
and define any and a pattern anyElement as
any= (attribute * { text }
| text
| anyElement)*
anyElement = element * { any }
Again the conformance for such markup can say: ignore it (it meaning:
markup from other namespaces) or process it. I think you are basically
saying that already at http://www.w3.org/TR/widgets/#extensions
Agreed. Our schema will be updated to include the above.
Thank you again for your help! And looking forward to hearing any
feedback you might have,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] i18n span element VS unicode RLM/LRM
Hi Felix,
I've passed your schema related comments to our schema maintainer
(David Håsäther, CC'd). Unless David has any comments, objections or
modifications, I would expect to see your recommendations in the
schema in the next publication.
Thanks again!
On Thu, Oct 9, 2008 at 12:49 AM, Felix Sasaki [EMAIL PROTECTED] wrote:
snip
after looking at this again I am thinking you could also say:
any= (attribute * - w:* { text }
| text
| anyElement)*
anyElement = element * - w:* { any }
-w:* (assuming that the w prefix is bound to the widgets namespace)
means that you exclude native widgets markup from the any defintions. That
is just a suggestion, no need to handle this as a formal comments.
Regards, Felix.
Kind regards,
--
Marcos Caceres
http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. I see what you mean, the Hoffman draft above reads more like a here is a list of what is wrong with file: rather than a spec. And rfc1738 has been obsoleted. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. We use both relative and absolute URI references, and the base is derived from the i18n model we have introduced. The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). Personally, the solution I keep coming to is something like : widget-uri = http://; widget-engine [: instance-id] / package-name path-absolute [# fragment] Where widget-engine is something akin to using, say, localhost, but uses some arbitrary string that identifies the engine (e.g. theFooEngine). The optional instance-id would be a string that uniquely identifies a widget instance for the purpose of cross-widget communication. However, I can foresee that there may be problems with thieving http's port semantics to uniquely identify an instance (so we leave this out until version 2). The scheme would only support GET requests. For example, http://theFooEngine/barWidget.wgt/index.html#welcome Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Updates FPWD published
Hi Henri, On Fri, Oct 10, 2008 at 8:38 AM, Henri Sivonen [EMAIL PROTECTED] wrote: On Oct 10, 2008, at 01:44, Marcos Caceres wrote: http://www.w3.org/TR/widgets-updates/ As always, comments welcomed. The sentence An update source is the URi referenced by the src attribute of the an update element. probably means the *widget*update element. Fixed. The Editor's Draft link points to the Editor's Draft of another spec. Fixed (Thanks Mike!). The processing model should probably say that non-DOM implementations are allowed if the result isn't black-box-distinguishable. Added a note to such effect (based on what we have in the other Widget specs): Note: The following processing model is written with more concern for clarity over efficiency. As such, user agents may optimize the processing model so long as the end result is indistinguishable from the result that would be obtained by the following the specification. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
On Fri, Oct 10, 2008 at 8:35 PM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 3:29 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok. I will add Any hierarchical URI scheme as the proposed solution into the spec. I will say that, personally, I feel it is irresponsible for the WebApps WG to not recommend a complete and a secure solution for this issue. I also fear that not mandating a URI scheme will lead to interoperability issues (especially going forward into V2, where we might want to support things like queries and fragments, which something like file: does not support). Well, the questions I asked of you were intended to discover whether or not interoperability was impacted by not specifying a URI scheme. Is there some aspect of this I didn't consider? Can you give me an example of an interoperability (or security, as you say) problem that's created by not specifying a URI scheme? Ok, In one of my previous emails I said that this was a potential privacy/security issue: The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Updates FPWD published
resource is cryptographically signed and the widget user agent validates the signature before installation, a widget resource's identity and integrity should be guaranteed. This is true in most situations. However, because of the high cost of getting a code signing cert, I imagine most widgets will be shipped unsigned. There are a few situations where this does not work. For example, if I shipped my original widget unsigned, then my second widget signed, then blackhat could remove the signature from the updated widget package and make evil changes. Given your suggestions, I've changed the text in this section to: It is conceivable that the automatic update model could be subject to a man-in-the-middle-attack, as with any unencrypted requests performed over HTTP. For this reason, it is recommended that, for widgets that have not been digitally signed, updates are be always performed over HTTPS. Another means of protection is for authors to always digitally sign their widget resources. During an update, the widget user agent will then validate the signature before installation, ensuring that a widget resource's identity and integrity was maintained over the network. The widget user agent will also verify that the digital signatures of the currently installed widget and the potential update certifiably came from the same source. WRT that last sentence, we still need to work out the details of how we will do that. j) 10.1 Using an Update Description Document: Replace widget engine by widget user agent. fixed. k) 10.1 Using an Update Description Document: Replace text/xml by application/xml. fixed. l) 10.1 Using an Update Description Document: So, the widget engine then checks that update id matches widget id and that widget version and update version are different. If so, then the user is informed that a new update is available. If the widget version is not the same like the update version, then this will not necessarily mean that a new update is available. The installed Widget Resource could have been retrieved from a web server providing the latest version. The UDD could have been stored on a memory card which could then be quite old. Then the widget user agent must be intelligent enough to compare whether the widget version is smaller than the update version. If yes, then a new update is available. The question is also whether we define a format for the version number. Is 1.0 older than 1.0a? No, they are just different. There is no notion of greater version in this specification. This makes the model much more flexible (it allows for rollback, etc). We had a long email discussion about this about a year ago [1]. See in particular, Ian Hickson's comments [2]. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-appformats/2007Sep/0006.html [2] http://lists.w3.org/Archives/Public/public-appformats/2007Sep/0026.html -- Marcos Caceres http://datadriven.com.au
Re: Widget Requirements feedback
Hi Addison and i18n-WG members, On Wed, Oct 15, 2008 at 3:09 AM, Phillips, Addison [EMAIL PROTECTED] wrote: Hi, I have just now reviewed all of your responses again and am satisfied (within the limits of what you can reasonably do, especially wrt the Zip limitations :-)). Thanks for working with us on this. Excellent! thank you and thanks to everyone in the i18n-wg for taking the time to help us out! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, Please see [1] for TAG discussion about WebApps proposal of widget URI scheme. From what I got from the discussion, the TAG seems to agree that we likely do need our own URI scheme. We just need to flesh out our technical argument a little more. We are also going to try to coordinate with the Open Document Format people as they also need something very similar. I again ask for your help in defining the scheme correctly, rather than arguing against it. [1] http://www.w3.org/2008/10/20-wam-minutes.html#item11 Kind regards, Marcos On Mon, Oct 13, 2008 at 4:59 PM, Mark Baker [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 10:31 AM, Marcos Caceres [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 5:08 AM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 4:00 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok, In one of my previous emails I said that this was a potential privacy/security issue: The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. Sure, but standardizing on a URI scheme won't fix this, because one can guess URIs in any scheme. Less opaque schemes like hierarchical ones are a little more susceptible of course, but it's a problem for all schemes. In the case of widgets, it's not a problem at all for the structure of the package to be guessed (as anyone can just decompress the widget locally anyway and take a look at it's directory structure; that is not the issue). What we don't want is a situation where the underlying operating system is also exposed. That is why we proposed the new scheme. I don't see how a scheme like widget://myWidget.wgt/path/to/file exposes anything about the underlying file system (apart from the name of the widget package)? Instead, file: exposes way too much IMO (i.e. file:///Users/marcos/Library/...! my username is exposed in the path, which everyone can acknowledge is pretty a bad thing, no?). file:, despite the name, doesn't have to be mapped to the file system. Its scope could be limited in exactly the same way you've limited widget: there. Similarly, ftp or http - even part of the space - *could* be mapped to the file system. So the issue you're worried about has little to do with the URI scheme. I suspect implementors are familiar with this issue already, but if you like, you could point out that implementations should ensure that widgets can't access local resources that the implementation doesn't want them to access. We will of course point out that implementations should ensure that widgets can't access local resources. That is explicitly part of the requirement for the URI scheme. Good. Mark. -- Marcos Caceres http://datadriven.com.au
[widgets] Version string
Hi All, I would like to relax a valid version string to be any string. The reason I want to do this is to make it easier to parse a version string without requiring any special processing (any string will do). We will still recommend the MIDlet Suite Versioning where Version numbers have the format Major.Minor[.Micro] (X.X[.X]). This affects the widget element's version attribute and parts of the Updates spec in a minor way. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] id attribute rename
HI All, After discussions on IRC, it has become clear that we need to rename the widget element's id attribute: [17:24] Hixie the real question is not what allowed values it has, but whether it should be used for CSS #id matching or DOM getElementById() matching [17:24] Hixie if it shouldn't, then don't call it id= [17:24] Hixie if it shoul, do [17:24] tlr-off or for any other matching-by-id, that is [17:24] tlr-off indeed [17:25] tlr-off e.g., xpath We don't use widget id in the manner above. Any suggestions? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Widget locale
Hi Jere, On Thu, Oct 23, 2008 at 11:39 AM, Kapyaho Jere (Nokia-TP-MSW/Tampere) [EMAIL PROTECTED] wrote: The definition of 'widget locale' is currently not in sync in the 'Widgets 1.0: Packaging and Configuration' [1] and 'Widget 1.0: APIs and Events' [2] specs. The locale issue has been mentioned earlier by Addison Phillips (comment #16 in [3]) and fixed, but I just noticed that the APIs spec mentions ISO 639-2 codes, and not BCP 47 tags. Thanks for pointing this out. We will fix this in before the document gets published. The question also remains how the widget engine reports the system locale to the widget as a BCP 47 language tag, if the engine itself is implemented on a platform that uses a different locale identification mechanism (which is highly likely). In that case some mapping is inevitable, and even though this is most likely implementation dependent, maybe a mention to that effect would be useful. We will be sure to include a note about this. We will let you know once we've added it so you can check that it is ok. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Version string
On Tue, Oct 28, 2008 at 3:29 PM, Mark Baker [EMAIL PROTECTED] wrote: Right. It's just like an etag, only not an etag 8-) LOL! right :) -- Marcos Caceres http://datadriven.com.au
Re: [widgets] id attribute rename
After todays teleconf, we have four candidates for renaming the widget element's id attribute: * widgetid * uid * wid * name My preference is uid, which is what I have put in the spec for now. I don't like widgetid, because it looks weird name to widget widgetid=blabla I don't like wid, because wid doesn't mean much to me. I don't like name, because it would mean renaming the name element to title (which goes against every widget user agent already using name as we have specified it) I like uid, because it implied unique id to me. Kind regards, Marcos On Mon, Oct 27, 2008 at 4:32 PM, Marcos Caceres [EMAIL PROTECTED] wrote: HI All, After discussions on IRC, it has become clear that we need to rename the widget element's id attribute: [17:24] Hixie the real question is not what allowed values it has, but whether it should be used for CSS #id matching or DOM getElementById() matching [17:24] Hixie if it shouldn't, then don't call it id= [17:24] Hixie if it shoul, do [17:24] tlr-off or for any other matching-by-id, that is [17:24] tlr-off indeed [17:25] tlr-off e.g., xpath We don't use widget id in the manner above. Any suggestions? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Minutes from 30 October 2008 Voice Conference
Hi Larry, On Sun, Nov 23, 2008 at 4:54 AM, Larry Masinter [EMAIL PROTECTED] wrote: Resolving the general topic of ZIP-based packages and URI references within them on the webapp mailing list doesn't seem practical, because those who need to review the package/URI issue are likely not interested in wading through the mass of other email on other unrelated topics within WebAPP WG. Valid point. I don't understand why setting up a separate mail list/archive/issue list on the specific topic is a lengthy process, it mainly requires the will to take the need for coherence seriously. Sorry, my understanding was that your wanted to set up a separate working group, which in my experience seems to take around 6 months. Setting a up a separate mailing list seems like a great idea. Who do we need to talk to to make this happen? Under which charter would this work be done? If resolving this in a timely fashion is important to you (as you seem to indicate by invoking time scope) then perhaps you might want to respond more quickly. I'm sorry. I only got back three days ago from vacation from somewhere far away from any internet connection. I'll try to be more prompt with my responses in the future. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
the
least. Why write a schema, which is a machine-readable version of mostly the
same rules which are described in prose, with precise semantics specifically
crafted by authors of the schema language to facilitate expressing such
rules, and then not include it as normative?
As I argued in my previous email, I think because schema and
validation misleads authors (this is evident in XHTML, where one's
markup can be complete crap but totally valid; hence devaluing
validation as a whole). I agree that parts of the validation process
can be mechanized (eg. don't put tag x inside tag y), but the
conformance/validity of content within a tag usually cannot usually be
checked by a machine. And that is where the real problems with
validation begin (eg. pI'm a heading, realy!/p or, in the case of
widgets, authorda plane! da plane!/author). Sure, it is a
politically biased decision to not make the schema normative; I'll be
the first to admit that! But it can be easily shown that the RelaxNG
schema for widgets does not fully express the prose or the parsing
algorithm. If it did, then we write the spec in a schema langauge and
not in prose.
Regardless of the normative or informative status of the schema, it
will still be part of the spec and will receive as much attention as
all other aspects in terms of quality. Conformance checkers and
authoring tools will be encouraged to make use to the schema.
However, I agree that contradictory to the
system is convoluted. Any suggestion of what I might change it to?
I'd probably go for unfeasible [for the user agent] or unfeasible {maybe
impossible} to realize {maybe satisfy or satisfy (realize) or satisfy
or realize} by the widget user agent.
I went with impossible to satisfy or realize by the user agent
: widget width=100-20/. I guess that is an error, but I'm just
trying to say that the author should not be punished. Should I just
drop that bit of the statement?
Yes, I believe so. It suggests being erroneously declared is some definite
condition distinguished from being in error.
Dropped.
HTML has to be enhanced in order to
meet the accessibility requirements
The problem is not with HTML but with scripts. And almost none of them
(particularly all written in ECMAScript et al.) would work but for the
assumption (nowhere specified, pending Window Object 1.0's progress to Rec)
that the global object implements the AbstractView interface (which includes
the crucially important document property). But I feel this is already far
enough from the present topic.
Agreed. Thank you again for your feedback.
--
Marcos Caceres
http://datadriven.com.au
Re: Widget testing
Hi Kai! On Fri, Nov 7, 2008 at 1:16 PM, Kai Hendry [EMAIL PROTECTED] wrote: Hey guys, I have an action to tell you what I've been upto WRT widgets http://www.w3.org/2008/11/04-mwts-minutes.html#action02 I've started working one day a week on widget testing. My own git repo is here: http://git.webvm.net/?p=wgtqa and it will move to a W3C CVS soon. I've come across a couple of issues which I've mailed Marcos already about. Though I'll paste them in here just in case: Subject: http://dev.w3.org/2006/waf/widgets/#the-license Having a optional URI or href whatever for the license would be good. Seems to be some inconsistency between src, uri, url, href btw that you can easily pick up in the relaxng scheme. I'm not comfortable with adding an optional URI. It implies that a license could change on the web without the user knowing about it. That really concerns me. http://dev.w3.org/2006/waf/widgets/#the-author xml:lang is not needed and it's not in your relaxng schema besides. Yep. The schema will only be updated once we finish spec'ing. I don't want to waste David's time updating the schema when the spec is still changing. I might remove the schema all together till we get to last call. It causes too much confusion at this point because it is maintained independently of the spec. Subject: http://dev.w3.org/2006/waf/widgets/#the-widget0 Bit confused by its:dir on widget, name, description, author etc. Can you describe the confusion? What should I put into the spec to make things more clear? The RelaxNG compact schema uses the bdo element and so does HTML5 so can't we just rock with that? http://git.webvm.net/?p=wgtqa;a=blob;f=widget.rnc As above. I've also written a little widget validation tool, which uses my updated (probably wrong) schema (widget.rnc). Try foo.wgt out like so: curl -F [EMAIL PROTECTED] http://wgt.webvm.net/ Great! If you have any comments or you'd like to help us out over at http://www.w3.org/2005/MWI/Tests/ then please get in touch. I'm also on IRC as 'hendry'. Enjoy the weekend, Thanks for your help Kai! -- Marcos Caceres http://datadriven.com.au
Re: Widget testing
On Mon, Nov 24, 2008 at 10:04 PM, Thomas Roessler [EMAIL PROTECTED] wrote: On 24 Nov 2008, at 22:46, Marcos Caceres wrote: Subject: http://dev.w3.org/2006/waf/widgets/#the-license Having a optional URI or href whatever for the license would be good. Seems to be some inconsistency between src, uri, url, href btw that you can easily pick up in the relaxng scheme. I'm not comfortable with adding an optional URI. It implies that a license could change on the web without the user knowing about it. That really concerns me. It's not that uncommon to use URIs to identify (well-known) licenses, see, e.g., http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/ http://www.ietf.org/rfc/rfc4946.txt I'd suggest that it's a good idea to enable this pattern for widgets; the issue that you point out (licenses changing after the fact) is one that's being dealt with on a social level. Grumble, grumble... alright, I'll add it... but I still don't like it :) -- Marcos Caceres http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Fri, Nov 28, 2008 at 3:52 PM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: I just wanted to float an outline of a not very baked idea for trying to solve the widget referencing problem with a media-type/fragment identifer approach - those IMO being the 'right' extension point in the web architecture to be trying to use for this purpose - ie a frag id syntax to go with a new or refined media-type specification for a packaging format. One vital requirement for the packaging format is that it maintains media-types for the things that the package contains so that the whole approach can nest. This idea is inspired by (my half rememberings) of source routed email addresses where % get re-written to @ and right hand domains get eaten off of mail addresses so that say: [EMAIL PROTECTED] progresively becomes: [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] as the message is routed via example.com, somerelay.com, isp.com and finally hp.com. The approach below 'works' left to right stripping away the none fragment part of a URI and rewriting the leftmost ! in the remaining fragment with a # as one penetrates more deeply into a package structure. I don't mean to suggest that this is all properly worked out - I may have violated numerous character restrictions in URI syntax. But in principle I think something like this could meet the widget addressing (and more general thing within package addressing) problem entirely within fragID/media-type space (which then leave it properly orthogonal to URI scheme). Consider a package/containment structure as follow (where indentation represents path depth and n: [..] represents named containment). outer: [ catalog.xml scripts myScript.js lib myLib.lib aLib.lib nestedPackages innerpkg: [ catalog.xml scripts nestedScript.js deeperPkgs moreNestedPkg: [ catalog.xml scripts deeplyNested.js ... ] ] mypkg: [ catalog.xml ] ] An external reference to some target XML in the most deeply nested catalog.xml 'file' would look like this: scheme://authority/path/outer#/nestedPackages/innerpkg!/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId Once focus shifts inside the outer package, references are re-written by replacing the leftmost ! with a # as follows: - from within outer - /nestedPackages/innerpkg#/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId - from within innerpkg - /deeperPkgs/moreNestedPkg#/catalog.xml!targetXMLId - from within moreNestedPkg - /catalog.xml#targetXMLId Relative references within a package hierarchy work as expected. Relative Referencing more deeply into the package structure is straight forward. Relative referencing up the hierarchy is not covered by this approach, though maybe another character could be reserved to act a bit like .. but at the package hierarchy level as opposed to internal to the package - I suppose that .. itself could be allowed to take you higher than the local package root - but some detailed work would have to be put in to checking compatibility with the normalisation of relative references in 3986. The assumption here is that the package format also maintains media-type information for each of the things that it contains that all the packages, outer, innerpkg, moreNestedPkg and mypkg are marked with a media-type that defines a fragment identifier syntax and re-write rules as illustrated above. Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Kind regards, Marcos [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#content-type-0 -- Marcos Caceres http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Stuart, On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: snip Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Web Apps does not have a problem having a dependency on HTML5 (particularly if the relevant section of HTML is proven to be stable by interoperable implementations). It might mean that Widgets sits on CR for 10 years, but that's ok with me at least. Sitting in CR for endless years didn't do any harm to CSS. However, if it does becomes a process problem for Web Apps, we might lift the relevant text out of HTML5 and put it in the Widgets spec. Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Right. The new proposal is that we use file extension mappings to MIME types, and if that fails, result to sniffing. We are reluctant to introduce a meta-data format at this point. For version 2 of widgets, it might be useful to either introduce the meta-data format or have an Apache-like file extensions to MIME type mapping. For example: image/gif .gif Note however, that widget engine in the wild have no problem working without MIME info. From what I have seen, they all do just fine either sniffing or using file extensions to derive the content types. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. I'm not sure it is. When a MIME type is registered with IANA, the file extension is also registered. So one has a standardized way to derive the media type for a file by the file extension. So I guess it might make sense to have a table of common file extensions and related MIME types baked into the Widget spec for formats that the widget spec mandates support for (e.g., .html, .css, .js, .gif and so on). Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Ok... but you answered a different question. I asked which of your requirements would an approach like this *fail* to meet? ok, sorry. I should have answered that correctly: 1. The path part of the scheme://authority/path/ does meet our requirements iff by path you mean path as defined in RFC2396 (with the ability to be an iPath as in RFC3987). 2. the scheme://authority/path is the bit Web Apps really needs to sort out. I.e., what will we call the scheme?: widget:? zip:? package:? or something else? what will be the authority? will it be the package itself: zip://myZipfile.zip? or the widget engine zip://engine/someZip.zip/? and so on... do we need an authority at all? I think these, and probably about a dozen more questions, need to be addressed before we jump the gun and start solving secondary use cases (addressing inner inner packages) I could paraphrase your response as: That would work, but it does more than we need. Dan Brickley's response[a] emphasised the need for nesting packages in packages. Even if that is not a capability that widgets would need to use, widgets could still share the same syntax. Dan's problem may be a general problem, but I need to empathize that it's not a requirement in the widget world. We could live with a shared syntax, of course. However, what worries me is bloating the scheme with features that may be rarely used, expensive to implement, and introduce another attack vector. For those reasons alone, I would like us to develop the scheme to be as simple as humanly possible and meet the most fundamental use cases/requirements ([1], [2]) before anything else. Anyway... I think that my sketch shows that there is a potential to develop a media-type + fragID-syntax based solution to the package component/widget addressing problem. Completely agreed. But can we please work on the scheme, authority and path bits first? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au [1] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing [2] http://dev.w3.org/2006/waf/widgets-reqs/#r36.-
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Mon, Dec 1, 2008 at 5:31 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Williams, Stuart (HP Labs, Bristol) wrote:
Well there are ways around that, add a package description
or meta-data file either at the root of the package or at
each directory level and have it carry media-type information
- or use 'magic numbers' or (if you really must - in the
absense of other authoritative information), sniff/guess
though I think that should be the least preferred option.
Right. The new proposal is that we use file extension mappings to MIME
types, and if that fails, result to sniffing. We are reluctant to
introduce a meta-data format at this point.
(Just allow RDFa+XHTML and leave it to the marketplace...)
right :)
For version 2 of widgets,
it might be useful to either introduce the meta-data format or have
an Apache-like file extensions to MIME type mapping. For example:
image/gif .gif
Note however, that widget engine in the wild have no problem working
without MIME info. From what I have seen, they all do just fine either
sniffing or using file extensions to derive the content types.
Anyway - that zip files don't intrinically maintain such
info is not a show stopper - though I would have thought that
carrying media-type information is a natural requirement for
a packaging format for the web.
I'm not sure it is. When a MIME type is registered with IANA, the file
extension is also registered.
What is registered (RFC 4288 section 4.11) is a list of file name
extensions commonly used with the media-type.
It does *not* reserve the extension for exclusive use with that
media-type.
It does *not* prevent other arbitrary file name extension or indeed
no-extension being used.
So... yes not a bad hint, but nothing is certain.
So one has a standardized way to derive
the media type for a file by the file extension.
Not with certainty...
So this seems like a very small piece of metadata ('this filetree follows
the IANA filename to media type mappings') has a lot of value. If the
versions of the IANA mapping are easily identified, the metadata becomes a
URI rather than a single bit. Either way, you can gain a lot from not a lot,
I think.
So we are clear, what do you have in mind here?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Stuart, On Mon, Dec 1, 2008 at 4:37 PM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: -Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 15:28 To: Williams, Stuart (HP Labs, Bristol) Cc: [EMAIL PROTECTED]; public-webapps Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Hi Stuart, On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: snip Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Web Apps does not have a problem having a dependency on HTML5 (particularly if the relevant section of HTML is proven to be stable by interoperable implementations). It might mean that Widgets sits on CR for 10 years, but that's ok with me at least. Sitting in CR for endless years didn't do any harm to CSS. However, if it does becomes a process problem for Web Apps, we might lift the relevant text out of HTML5 and put it in the Widgets spec. Your or your WG's call. Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Right. The new proposal is that we use file extension mappings to MIME types, and if that fails, result to sniffing. We are reluctant to introduce a meta-data format at this point. For version 2 of widgets, it might be useful to either introduce the meta-data format or have an Apache-like file extensions to MIME type mapping. For example: image/gif .gif Note however, that widget engine in the wild have no problem working without MIME info. From what I have seen, they all do just fine either sniffing or using file extensions to derive the content types. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. I'm not sure it is. When a MIME type is registered with IANA, the file extension is also registered. What is registered (RFC 4288 section 4.11) is a list of file name extensions commonly used with the media-type. It does *not* reserve the extension for exclusive use with that media-type. It does *not* prevent other arbitrary file name extension or indeed no-extension being used. So... yes not a bad hint, but nothing is certain. Agreed. But you get the same problem with mislabeled types in HTTP. In the majority of cases the file extension will be correct. So one has a standardized way to derive the media type for a file by the file extension. Not with certainty... So I guess it might make sense to have a table of common file extensions and related MIME types baked into the Widget spec for formats that the widget spec mandates support for (e.g., .html, .css, .js, .gif and so on). Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Ok... but you answered a different question. I asked which of your requirements would an approach like this *fail* to meet? ok, sorry. I should have answered that correctly: 1. The path part of the scheme://authority/path/ does meet our requirements iff by path you mean path as defined in RFC2396 (with the ability to be an iPath as in RFC3987). Which part of http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing says that? I do not see that stated as a requirement there. It would be overly prescriptive for us to have the solution in the requirement. The requirement basically boils down to: relative and absolute addressing (in the path-sense). This requirement is just concerned with having a path (not a full URI scheme). 2. the scheme://authority/path is the bit Web Apps really needs to sort out. I.e., what will we call the scheme?: widget:? zip:? package:? or something else? what will be the authority? will it be the package itself: zip://myZipfile.zip? or the widget engine zip://engine/someZip.zip/? and so on... do we need an authority at all? I think these, and probably about a dozen more questions, need to be addressed before we jump the gun and start solving
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 2, 2008 at 6:09 PM, Boris Zbarsky [EMAIL PROTECTED] wrote: Marcos Caceres wrote: That wouldn't be a problem in widgets, as we would say .css is always text/css. My point is that this doesn't seem like a reasonable requirement, necessarily. Do you have any suggestions as to how we might move forward? Or a different approach to solving the problem? -- Marcos Caceres http://datadriven.com.au
[widgets] Trimming attribute values, a bad idea?
Got a question... I've relaxed keyword attributes to be allowed to have leading and trailing whitespace. Now, widget user agents are required to trim whitespace prior to validation/processing. Widget user agents must only perform literal comparisons with trimmed values, and must not perform case insensitive comparisons. So, for instance, access network= false is ok. Does anyone see any problem with this? Should I revert back to being strict and having UA do comparisons without trimming? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Trimming attribute values, a bad idea?
HI Simon, On Wed, Dec 3, 2008 at 8:25 AM, Simon Pieters [EMAIL PROTECTED] wrote: On Wed, 03 Dec 2008 03:51:13 +0100, Marcos Caceres [EMAIL PROTECTED] wrote: Got a question... I've relaxed keyword attributes to be allowed to have leading and trailing whitespace. Any particular reason for this? :-) Just to be nicer to authors. Now, widget user agents are required to trim whitespace prior to validation/processing. Widget user agents must only perform literal comparisons with trimmed values, and must not perform case insensitive comparisons. In HTML5, enumerated attributes are ASCII case-insensitive with no leading or trailing whitespace allowed. I'm not sure how SVG and MathML handle enumerated attributes, though. Ok, I'll follow HTML5 on this. -- Marcos Caceres http://datadriven.com.au
[widgets] URI attribute naming
Kai recently raised a question with regards to the naming of attributes that take either URIs or paths as values (for example, content src=some/file.html). I wanted to clarify the choices I made here and seek feedback. In the spec, there are essentially 3 types of URI attributes: paths, hyperlinks, identifiers. ==Paths== Either absolute or relative paths, for addressing resources inside a widget package. Any attribute that is a path shall be named src. This applies to the following elements: * content * icon Technically, paths are not URIs (but they are resolved to URI's at runtime... well, they will be one we sort out the widget URI mess). ==hyperlinks== A hyperlink is a URI that points to some resource on the Web that is either meant to be retrieved by use action (e.g. by clicking), or retrieved automatically by the UA at its convenience. Any attribute that is a hyperlink will named href. This applies to the following elements: * author * license * update ==identifiers== There are two instances where identifiers are used. For the widget element's identifier wid and for the feature element's name attribute. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Trimming attribute values, a bad idea?
Hi Jere, On Wed, Dec 3, 2008 at 8:38 AM, Jere Kapyaho [EMAIL PROTECTED] wrote: On 3.12.2008 4.51, ext Marcos Caceres [EMAIL PROTECTED] wrote: Got a question... I've relaxed keyword attributes to be allowed to have leading and trailing whitespace. Now, widget user agents are required to trim whitespace prior to validation/processing. Widget user agents must only perform literal comparisons with trimmed values, and must not perform case insensitive comparisons. So, for instance, access network= false is ok. Does anyone see any problem with this? Should I revert back to being strict and having UA do comparisons without trimming? In the context of XML, I guess that instead of 'trimming' a slightly more accurate term/concept would be 'attribute value normalization' [1], which also includes compressing runs of white space into one. An interesting discussion appears in 'Processing XML with Java' [2]. Based on that, it might be better to just *not* do it, but then you wouldn't be XML compliant. (So you could say that if an implementation doesn't, then it isn't.) I see. Note that in XML this is specified in terms of DTD datatypes, but the config document is described in RELAX NG. It might not make a difference; maybe [3] gives a better idea about how this pans out in practice. [1] http://www.w3.org/TR/REC-xml/#AVNormalize [2] http://www.cafeconleche.org/books/xmljava/chapters/ch01s02.html#d0e951 [3] http://books.xmlschemata.org/relaxng/relax-CHP-7-SECT-4.html Ok, thanks for those resources. They were very useful! -- Marcos Caceres http://datadriven.com.au
[widgets] Window modes
We currently have gap in the Packaging spec wrt window modes of widgets. We began to define the following, but did not get very far: * window: appears with chrome around it. * fullscreen: No chrome, not resizable. * floating: No chrome, floating window (dragable, author re-sizable via code). * hidden: No visible. * default: Let the implementation decide. I'm not sure how to proceed with regards to window modes. We need to define them somewhere, but they are going to hold up the packaging spec. I think the Packaging spec should only list the name of the modes, as they are needed by the widget element's mode attribute, but not their behavior/rendering, which should be specified somewhere else... but I don't know where. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Art, On Thu, Dec 4, 2008 at 12:48 PM, Arthur Barstow [EMAIL PROTECTED] wrote: Marcos, On Dec 3, 2008, at 5:03 PM, ext Marcos Caceres wrote: A widget user agent would be expected to support the above types. All other types are optional. All proprietary types, apart from ico, are optional. What - if anything - will be prescribed (normative) here for the various conformance classes? The spec will contain a table of file extensions, corresponding MIME types, and magic numbers (unique byte sequences for sniffing). User Agents would be expected to use table to derive the MIME type interoperably. I scanned the new Section 6.1 and didn't notice any testable assertions: http://dev.w3.org/2006/waf/widgets/#files A testable assertion would be to check that, for instance, a .html file is being process as text/html and not as application/xhtml+xml. A bunch of tests could be developed where files have no extensions and a widget user agent is expected to correctly process each file. Another testable assertion would be to make sure that either sniffing or file extension checking is done first. From reading [1], seems that sniffing is performed by browsers first. If sniffing cannot determine the type, file extension is used as a fallback. So, another testable assertion would be to create a index.jpg file (with HTML content) and make sure it does actually get rendered as text/html. Or create a image.html with png data and make sure that it does get rendered as image/png. And so on... Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Stuart, On Thu, Dec 4, 2008 at 8:02 PM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: Marcos, The TAG suggested that I re-post the idea that I floated at the beginning of this thread on the new list at [EMAIL PROTECTED] and encourage any continuation of this thread to take place there - which I have now done [1]. Also, with some irony, I think that I'm beginning to get a better understanding of your problem, the key for me being your assertion in an earlier messages: I think we have different goals in respect to [3], and that might be causing me confusion. For instance, Widgets do not have a need to remotely access and reference items within a web accessible package. Conversely, Web apps just needs to access files within a locally stored package. Your problem is centered around how to generate absolute URI from package relative URI driven primarily by a need for API compatibility rather than a need to be able to make global sharable references. yes :) I know, that's a bit short sighted. I don't know whether ...do not need to... means simply ...don't... or even more strongly ...will never have to If the possibility exists then I think that your requirements need to take that into account. OTOH if it is *never* going to happen... I'll have to scratch my head a bit more to think about how you'd come up with a base URI and what the risks were of essentially a locally scoped identifier escaping into the wild by accident. I think we are both starting to see each others' position more clearly, which is great. So, to be clear: at this moment in time, in what we are specifying for Widgets 1.0, our position is that that widgets don't need to remotely access or reference items within a Web accessible package. However, this does not means we would not want to do that in the future. So if that functionality is specified as part of this effort, then that is a good thing and widgets may use it. In regards to the URI leaking. Admittedly, as WebApps does not actually have any concrete proposal for a widget:// URI scheme, I honestly have not given any thought to identifiers escaping into the wild by accident. The first hurdle has been to prove that a new URI scheme is even needed. I'm not sure if WebApps has successfully even jumped that first hurdle yet. Anyway, I'm looking forward to working with everyone on addressing [3], but hopefully people will also be inclined to help us with the problem we have with widgets. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Laurens, 2008/12/5 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .html .htm .css .gif .jpeg .png .js .json .xml .txt The following we should probably bake in too: .mp3 .swf .wav .svg .ico We may bake in the following: xhtml Why 'may'? It seems to me that application/xhtml+xml deserves a MIME type mapping just like text/html does. Unless you have a personal preference for text/html and want to perpetuate that in this specification? ;) Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Fri, Dec 5, 2008 at 5:19 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Marcos Caceres wrote: Hi Laurens, 2008/12/5 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .html .htm .css .gif .jpeg .png .js .json .xml .txt The following we should probably bake in too: .mp3 .swf .wav .svg .ico We may bake in the following: xhtml Why 'may'? It seems to me that application/xhtml+xml deserves a MIME type mapping just like text/html does. Unless you have a personal preference for text/html and want to perpetuate that in this specification? ;) Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). Ugh, please don't do that. XHTML treated as HTML is very bad [1]. Why not simply allow people to treat it as unsupported, just like i'd imagine implementations that don't support wav, svg or json to do. It was mainly because of [1] that I Ieft xhtml out. I don't want to encourage authors to use xhtml with widgets if it's not going to be widely supported by widget user agents (no implementer has asked for xhtml support to date). In Widgets version 2, we might introduce fallback on content, where you can do something like: widget content src=index.xhtml type=application/xhtml+xml cotent src=index.swf type=whateverTheFlash/typeIs content src=index.html type=text/html/ /content /content /widget -- Marcos Caceres http://datadriven.com.au
[widgets] Unicode Zip Paths (fully decomposed canonical form?)
Hi, I'm trying to put the final touches on the zip section of the widget packaging spec [1] before we go to LC by the 10th and I've run into an i18n problem related to character encodings. I' wondering if anyone would be kind enough to give me some guidance as to what is going on, encoding wise, with in MacOS with regards to the encoding of file names in Zip Files? When I create a zip file with one file entry called ñ, inside the zip file, the file name gets decomposed to the following (hex) byte sequence: ñ - 0x6E 0xCC 6E is the letter n in Unicode, so there is obviously some decomposition going on there. But 0xCC in Unicode maps to Ì (LATIN CAPITAL LETTER I WITH GRAVE)? So I'm not sure what encoding the zip file is using. The reason I ask is because I'm not sure what to put into the widget spec in regards to recommending the use of canonical decomposition for unicode file names. Or even if that is a good idea!? Should I put the following into the spec?: It is recommended that the file name field be encoded using [UTF-8] in fully decomposed canonical form. OR just: It is recommended that the file name field be encoded using [UTF-8]. This seems important for when I go form MacOS to any other platform as file names get all mangled when files are extracted on any other platform. We obviously don't want that to happen so widget engines need to be prepared to deal with these encoding issues. I looked at the Zip spec [2], but I don't see any real guidance with regards to this. However, for those who know more about encoding, it would be helpful if you could also take a look at the Zip spec. Any help would be greatly appreciated, Marcos [1] http://dev.w3.org/2006/waf/widgets/#zip-relative [2] http://www.pkware.com/documents/casestudies/APPNOTE.TXT -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Unicode Zip Paths (fully decomposed canonical form?)
Woops, by fully decomposed canonical form I think I ment Normalization Form D (NFD) as defined in: http://www.unicode.org/reports/tr15/#Decomposition On Sat, Dec 6, 2008 at 12:31 AM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi, I'm trying to put the final touches on the zip section of the widget packaging spec [1] before we go to LC by the 10th and I've run into an i18n problem related to character encodings. I' wondering if anyone would be kind enough to give me some guidance as to what is going on, encoding wise, with in MacOS with regards to the encoding of file names in Zip Files? When I create a zip file with one file entry called ñ, inside the zip file, the file name gets decomposed to the following (hex) byte sequence: ñ - 0x6E 0xCC 6E is the letter n in Unicode, so there is obviously some decomposition going on there. But 0xCC in Unicode maps to Ì (LATIN CAPITAL LETTER I WITH GRAVE)? So I'm not sure what encoding the zip file is using. The reason I ask is because I'm not sure what to put into the widget spec in regards to recommending the use of canonical decomposition for unicode file names. Or even if that is a good idea!? Should I put the following into the spec?: It is recommended that the file name field be encoded using [UTF-8] in fully decomposed canonical form. OR just: It is recommended that the file name field be encoded using [UTF-8]. This seems important for when I go form MacOS to any other platform as file names get all mangled when files are extracted on any other platform. We obviously don't want that to happen so widget engines need to be prepared to deal with these encoding issues. I looked at the Zip spec [2], but I don't see any real guidance with regards to this. However, for those who know more about encoding, it would be helpful if you could also take a look at the Zip spec. Any help would be greatly appreciated, Marcos [1] http://dev.w3.org/2006/waf/widgets/#zip-relative [2] http://www.pkware.com/documents/casestudies/APPNOTE.TXT -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Jonathan, On Sat, Dec 6, 2008 at 3:21 PM, Jonathan Rees [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:58 AM, timeless wrote: On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this. OK, if you need to distinguish the instances, give each a different tag: URI. You could identify the instance using an entropy-generated bit string, and maintain a mapping from bit string to instance. Or, if you have some other way to designate an entity internally, such as process id + index into a table, you could put that information, or a hash of it, into the tag: URI, in combination with entropy or some other hash if you like. I hope it is clear that I'm not specifying a particular way to choose the tag: URI, as I can't because I don't know details of your requirements or architecture (sorry). The question was: Using tag: you can do just about anything you want in the way of exposing and/or hiding information (probably ten or twenty options here depending on what information and entropy feeds in and how/when/whether it's hashed), so why not use tag: ? I certainly seems like a plausible solution, as it does, on the surface, give us all the aspects that we require: 1. per-instance identity. 2. a path to files inside the package. 3. extensibility through using comas in the authority part (with the ability to identify a domain of origin). 4. no conflict with existing implemented schemes in browsers. However, reading [1] there are some outstanding issues wrt compatibility with IRIs. It's unclear if that was resolved or not in rfc4151. In other words, if you think file: and http: have problems, the tag: URI scheme might provide a way out that does not require registering a new URI scheme. You still have a design problem (which you would have regardless), but at least you avoid one source of unpleasantness. Agreed. [1] http://www.taguri.org/ -- Marcos Caceres http://datadriven.com.au
[widgets] the widget spec needs you! Volunteer to help with references
I'm wondering if anyone out there might want to help me out by completing the references section of the widget packaging spec [1]? This would greatly help me to have the spec ready for publication by the 18th. It's not too much work (2 hours max), one would just needs to check that all references are up to date, update a few and add any references that are missing or incomplete. Hope someone will be kind enough to help me out! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets/ -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Typos
Hi Mohamed, On Sat, Dec 6, 2008 at 11:53 PM, Innovimax SARL [EMAIL PROTECTED] wrote: Dear, Please find some comments on the following spec : http://dev.w3.org/2006/waf/widgets/ (of the 6 december 2008) Regards, Mohamed ZERGAOUI == Typos == s/Lanaguage-Tag/Language-Tag/ fixed. s/expresssion/expression/ fixed. s/fobar.png/foobar.png/ fixed. s/langauge/language/ fixed. Thanks again. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Unicode Zip Paths (fully decomposed canonical form?)
Hi Martin, On Sun, Dec 7, 2008 at 7:56 AM, Martin Duerst [EMAIL PROTECTED] wrote: At 09:31 08/12/06, Marcos Caceres wrote: Hi, I'm trying to put the final touches on the zip section of the widget packaging spec [1] before we go to LC by the 10th and I've run into an i18n problem related to character encodings. I' wondering if anyone would be kind enough to give me some guidance as to what is going on, encoding wise, with in MacOS with regards to the encoding of file names in Zip Files? When I create a zip file with one file entry called nフ�, inside the zip file, the file name gets decomposed to the following (hex) byte sequence: nフ�- 0x6E 0xCC My mailer has problems with UTF-8, but my guess is that you are using n-with-tilde. In UTF-8 and NFD, that would be Ux6E 0xCC 0x83, so one explanation is that some data was dropped (and one way to explain that would be that the implementation was confused about characters vs. bytes). Apologies, I made a mistake. I had another look and no data was dropped by Apple's zip implementation. The byte sequence for n-with-tilde is as you said: Ux6E 0xCC 0x83 However, I was reading [1] and it turns out that MacOS might actually be using their own decomposition that resembles FCD. 6E is the letter n in Unicode, so there is obviously some decomposition going on there. But 0xCC in Unicode maps to テ�(LATIN CAPITAL LETTER I WITH GRAVE)? So I'm not sure what encoding the zip file is using. A single 0xCC byte doesn't map to anything in any Unicode encoding form. The reason I ask is because I'm not sure what to put into the widget spec in regards to recommending the use of canonical decomposition for unicode file names. Or even if that is a good idea!? Should I put the following into the spec?: It is recommended that the file name field be encoded using [UTF-8] in fully decomposed canonical form. No. Although the Mac file system(s?) use (a variant of) NFD, for file names, other operating systems (Windows, Linux,...) don't. If you want to specify a normalization form, NFC is closer to what the majority does. OR just: It is recommended that the file name field be encoded using [UTF-8]. Realistically, that's about what you can ask for. And that should be enough if the main concern is to match file names from the same source. If you need to assure that file names from different sources can be matched, then proscribing NFC is the best thing to do, but you may have difficulties to get your developers following your spec. Unfortunately, the concern is matching file names from different sources:( If this is lost cause, then I will stick with It is recommended that the file name field be encoded using [UTF-8]. This seems important for when I go form MacOS to any other platform as file names get all mangled when files are extracted on any other platform. We obviously don't want that to happen so widget engines need to be prepared to deal with these encoding issues. I looked at the Zip spec [2], but I don't see any real guidance with regards to this. However, for those who know more about encoding, it would be helpful if you could also take a look at the Zip spec. It looks to me that you should say that bit 11 should be set and UTF-8 should be used for file name and comment, unless there are a significant number of zip toolkits that don't allow that. I have this in the spec already, but I've been unable to determine if any implementation actually sets general purpose bit 11. The spec contains the following: The 0x0008 Extra Field storage may be used with either setting for general purpose bit 11. Examples of the intended usage for this field is to store whether modified-UTF-8 (JAVA) is used, or UTF-8-MAC. modified-UTF-8 means that surrogates are directly converted into 3-byte UTF-8(-like) sequences instead of converting surrogate pairs into 4-byte UTF-8. UTF-8-MAC is UTF-8, mainly NFD, but NFC for Korean. The specification of the 0x0008 extra field... is extremely vague, not useful at all. Yeah :( Thank you for your help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Mon, Dec 8, 2008 at 9:04 AM, Jonas Sicking [EMAIL PROTECTED] wrote: On Sun, Dec 7, 2008 at 10:11 PM, Simon Pieters [EMAIL PROTECTED] wrote: On Fri, 05 Dec 2008 15:53:22 +0100, Marcos Caceres [EMAIL PROTECTED] wrote: Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). I'd prefer if they treated it as application/xml instead. In fact, authors who want to use XHTML (or SVG, etc) in widgets could just use the .xml extension and it would work. In mozilla it gives different results if you serve usng application/xml, application/svg+xml or application/xhtml+xml. We create different types of Document nodes depending on what mimetype is used. So an SVG document, or plain XML document, won't have .cookies or .body for example. If this is ideal or not can of course be debated. I know Hixie has been advocating only having a single type of Document object, ever. Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
2008/12/10 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) XHTML is a W3C standard that's been Recommended status for many years and has plenty of implementations (except for Internet Explorer, at this time). This should be more than enough to warrant inclusion in the list of MIME type mappings. I'm against using the application/xml type for XHTML by the way. A more specific MIME type is available and it has its use in certain occasions (e.g. for content negotiation, to determine whether the UA is requesting a human-readable XHTML version or a site-specific machine-readable XML version). XML is a transmission format that a lot of different formats make use of, however each format using XML is still a format on its own and should have its own MIME type. E.g. application/xhtml+xml should not be confused with application/rdf+xml, even though both could be served as application/xml. The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content I'm not sure if any widget engines support application/xhtml+xml. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. However, if implementers request it, then we will consider adding it. Kind regards, Marcos [1] http://hixie.ch/advocacy/xhtml. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 9, 2008 at 10:06 PM, Adam Barth [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres [EMAIL PROTECTED] wrote: If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) I haven't been following the widget discussion very closely, so I apologize if this issue is understood already, but, in general, being able to coerce an arbitrary URL to application/xml is a big security problem. Can you point me to where the content tag is defined? The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content Would certainly appreciate more details about the security threat. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Laurens, 2008/12/10 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of 'widget engine', but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don't suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn't implement this specification anyway (neither do the other browsers, for that matter). Please read the spec for a definition of a widget user agent (widget engine). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. This encourages fragmentation. We don't want developers developing in XHTML at all if those widgets are not going to work interoperably on HTML-only widget engines (and yes, those exists! a reference implementation of this specification is being developed on pocket IE). We don't forbid xhtml (hence the content element's type attribute.) I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. I'm not going to be drawn into citations war about this. This isn't about that. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. And I quote, HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language [ISO8879]. The HTML4.01 spec says it's so. Browsers didn't follow the spec. By specification, HTML4.01 *is* SGML. If you deny this fact, then your notion of HTML has not been formally defined anywhere. Also, actually HTML5 does support exactly this (even though Hixie doesn't like it, last I heard). I'm not sure what this is. I also don't particularly care about what Hixie's position is on things. I'm capable of drawing my own conclusions from whatever evidence is available. Hixie's document, although advocating a position, formulates are logical argument backed by testable/verifiable evidence. Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification's subtitle is A vocabulary and associated APIs for HTML and XHTML. You are aware of this, right? right. I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. If it's purely optional, it's not necessary to have it in the Widget spec. The mapping to a file extension It's already defined here: http://www.rfc-editor.org/rfc/rfc3236.txt However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the 'HTML good, XML bad' mantra that seems to be popular among certain groups lately, and not hide behind statements like 'if implementors request it'. I don't appreciate you insulting me or other members of the working group by implying we are ignorant. I'm not hiding behind anything: as editor, my role is to represent the interests of members and the public in the spec. Also, I never said anything about good/bad aspects of HTML or XML. I don't understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. Why should XHTML get preferential treatment? By that logic I should also add RDF or whatever other obscure implemented specification supported by browsers. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. I don't have a personal preference (I think they both suck). When I worked as a proffesional Web developer, I
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Jere, On Wed, Dec 10, 2008 at 12:47 PM, Jere Kapyaho [EMAIL PROTECTED] wrote: Hi Marcos, finally I got the chance to read the Widgets 1.0 Packaging Configuration spec. Great work there; please accept some comments based on the Editor's Draft 7 December 2008 version, up at [1]. 5.3 Zip Relative Paths The ABNF needs some polishing: - Rule names like cp437 vs. cp437-chars, utf8-range vs. utf8-chars, ascii-range vs. ascii-chars. Fixed. - ABNF rules are case-insensitive as per RFC 5234 [2]; does this affect the Language-Tag rule in any way? No, they are also case insensitive. - delimiter should be %x2F or just / for readability used /. - In cp437-chars, should say %x80-FF (and no semicolon) fixed. - s/is define in/is defined in/ fixed. 5.4 Reserved characters - Minor issue with the table of reserved characters: the Unicode code points Fixed. column would be better labeled Unicode character and be made the first column. Fixed. The CP437 column is redundant, IMHO. Right. dropped it. The column Character representation could be just Representation or Representative glyph. Used Representative glyph. - Are filenames of ZIP entries case-sensitive or not? The ZIP spec does not seem to say (or I missed it), but the PC spec has several recommendations about case. I think they are case insensitive. So, if you have two file entries with the same file name (say a and A) inside a zip file, upon decompression, one will override each other. This is also a problem on operating systems that are case insensitive. 6.4 Content localization - Note that since localized folders now must reside in the root of the widget package, they pollute the root namespace, and it is possible to (more or less accidentally) have a normal folder whose name is a valid BCP47 language tag. In essence, all valid BCP47 language tags would have to be treated as reserved. Should the localized folders instead be placed one level down from the root, inside folder 'X', where 'X' is a suitable reserved name like 'resources'? I don't think this is necessary. We should maybe add a conformance checker behavior to warn authors about this. - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. Is this a problem with the way the algorithm in the spec is written? or is this a problem with with BCP47? We had this problem in JSR 238 [3], and ended up having a metadata entry that lists the supported locales. It can be generated by a widget packaging tool. Not ideal, but beats a combinatorial explosion... :) Or maybe you envision that the lang-priority-list removes the need to iterate? If the problem is with strangely formed langauge tags, I wonder if conformance checkers will help there? 6.5 Start file and Default Start Files See Step X for instructions of how to find the default start file. -- here X should probably be 9. Fixed. 8. Steps for Processing a Widget Resource Step 6 - Determine the base folder and widget locale - Algorithm step 2.d.i.2 seems to be missing something (Let base folder .). Ok, it's now Let base folder be the name of the folder that matched the current range. - Algorithm step 2.d.ii refers to this step 2.4. fixed. Should have been 2.d References - ZIP file spec: seems to be revised from time to time, would it be good to freeze the reference to a particular version? Agreed. We will probably freeze on 6.3.1. - Might want to fill in the HTTP, URI, ABNF etc. references before formal publication. BTW, did you already get someone to volunteer to do it? I'll help if not too late. I haven't had anyone volunteer (though Mohamed Zergaoui sent in some comments regarding what needed fixing[1]). I would _really_ appreciate any help you can give me! - Make all the URIs also links (like BCP47). Will do. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0436.html -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
On Mon, Dec 15, 2008 at 10:08 AM, SUZANNE Benoit RD-SIRP-ISS benoit.suza...@orange-ftgroup.com wrote: In vista sidebar also, the root folder is used without any specific intermediate folder name, and this can become very messy. For this reason I would advocate for the intermediate folder. I think we should push for the i18n naming as, even if it sounds a bit geeky, it is becoming a standard in the javascript frameworks, and using something else will introduce confusion. Can you please point me which frameworks are using i18n as a folder to contain localized content? -- Marcos Caceres http://datadriven.com.au
Re: Using W3C widgets in a web container: two implementations contrasted
Hi, Scott! On 1/14/09 7:55 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: All, Two EU-funded projects have implemented the draft W3C Widgets specifications, both the packaging and API parts. This is fantastic to hear. What is notable from these projects have been the adaptations used to enable widgets conforming to the draft to be used in a web environment rather than in a dedicated platform such as a browser, OS or device widget layer. We've documented and discussed the extensions and implementation approaches here: http://groups.google.com/group/talk-about-widgets/web/implementating-the-w3c-w idget-specification In brief, the Palette project has added W3C widgets functionality through developing the engine as part of an open-source portal web application, whereas the TenCompetence project developed a standalone open-source engine for adding widgets to multiple web applications, rather similar in approach to the Apache Shindig project for implementing Google OpenSocial. Interesting. In addition, both projects wanted to add additional functionality to the API; this has included state coupling and shared states to enable richer interaction between (a) widgets in the same user context and (b) instances of the same widget from different users (i.e. collaborative applications such as chat and voting). Note that though both were funded by the EC IST programme, Palette and TenCompetence had not been collaborating prior to a recent event where members of both were asked to provide papers, when we discovered we had undertaken parallel efforts at solving the same problems with the same specifications! Hopefully this gives others an opportunity to learn from our different approaches. Any feedback you have from implementing the packaging spec would be particularly helpful at this point. WRT APIs, we are very open to hearing what you have in mind. However, having looked at the link you sent above, I'm wondering why you didn't rely on XMLHttpRequest for doing the network requests? Both projects are focussed on networked learning solutions and research, for which Widgets provided an elegant solution to a number of issues in reaching learners and co-ordinating access to functionality. For more background on the projects themselves, see: http://www.tencompetence.org http://palette.ercim.org/ Thanks for this info. Kind regards, Marcos
Re: [widgets] PC 1.0 Last Call WD: localization comments
Hi Jere, On 1/14/09 3:28 PM, Jere Kapyaho jere.kapy...@nokia.com wrote: Hi Marcos, I have (still) a couple of concerns about the localization section of Widgets Packaging Configuration Last Call WD of 20081222. /1/ Is the following statement in [1] as it should be? Author requirements: Localized folders must be at the root of the widget (a localized folder not at the root of the widget will be treated as an arbitrary folder). I think it should now read: Localized folders must be placed inside the container for localized content (...). Fixed. /2/ I was looking at the localized widget example in the same section (it's non-normative, but important nonetheless), and it seems that the left and right sides of the example don't agree. The paths on the right are absolute from the root, not the container. Fixed. The right side shows en-au, but that is not found on the left side. The first bullet of the example mentions Korean, but that does not seem to be present. Should it be Spanish instead? Fixed. Finally, it's not obvious which of the files shown (if any) is the start file, because the content of config.xml is not shown. I've now added /config.xml to the right side. It includes a content/ element which hopefully makes things more clear. /3/ This is a potentially confusing statement: At runtime, the widget user agent will set the (HTML or XML) base of the start file to the localized folder (even if the start file does not reside inside the localized folder). I assume in this case the localized folder means the one determined in Step 6, right? This might not be obvious from the context, it requires a trip to the text of Step 6. This is correct. I've added a link to step 6 in the text: please refer to step 6 (does that help at all or should I elaborate more on it in the spec?) /4/ Since BCP47 tags are case-insensitive, it might be good to normalise all their occurrences to lowercase, to avoid any confusion. Ok, I wrote into step 3 that the wua-language list must be normalized to lowercase form. I modified step 6 also so the comparison is done in lower case. Can you please check that it is ok? /5/ Is there value in being able to have multiple config.xml documents, instead of just one, and tagging the relevant elements with a BCP47 tag? The example mentions different author and license, which could be expressed in one file. If you have a pointer to some earlier discussion that resolves this, it's fine. Or do you think it would make the config.xml document too bulky? Although we have had these discussions in the past, I don't have pointers but I am happy to summarize our thinking here. There are a number of reasons why we went with the multiple config file approach: 1. the XML I18n best practices guidelines says it that we should have multiple documents. See http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc 2. Like you said, makes the config files less bulky and, IMHO, easier to maintain. 3. Makes processing the XML easier and more predictable. Also, in a separate email I noticed you raised concerns about the use of not required in the Widgets digsig spec. I noticed that I had introduced the same problem into the the PC spec. I have gone through and changed all instances of not required to use the word optional. I'll make sure that doesn't happen in the other specs too. For the purpose of LC disposition of comments, can you please indicate if you are satisfied with the working group's response. Kind regards, Marcos
Re: Comments on Widgets 1.0 Security requirements
On 1/12/09 2:03 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Frederick, All, As promised on last week's call some further clarifications below on R44. Thanks, Mark (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.- This requirement is unclear. Is the intent to say that a signature associated with a widget package might be extracted and served to a client independently of the package, allowing the package to be delivered without the signature inside of it? Or is it saying that the certificate chain and/or revocation information should be able to be accessed independently of the package? In general it might not make sense to validate a signature without access the widget content, since that is not meaningful unless it is possible to validate the content hashes used to generate and validate the signature. [MP] Re-reading the requirement I agree we could have been clearer in what we were requiring, which is: 1. It MUST be possible to extract a _copy_ of the digital signature document(s) from the widget package. 2. It SHOULD (MUST?) be possible for the widget user agent to complete the signature validation processing for a digital signature document that is provided independently of a widget package (noting that the signature is not validated until the reference validation processing has also been successfully completed) When we write the specification text to meet this requirement we will need to ensure that the error cases are covered, e.g. when the independently supplied and packaged digital signature do not match. With these clarifications hopefully the requirement and rationale make more sense? Although one can extract a signature XML element from a widget package, I'm not sure how meaningful that is if one cannot subsequently locate the content that is signed - for example if a ds:Reference refers to an item in the widget package, how can an extracted signature be validated if that item is no longer available? Along similar lines, I might expect the URI for a resource to be relative if the signature is always enveloped (the signature is within the widget package containing the signature and other items) but perhaps a full URL for detached, when the signature is stored separately from the signed items. I do not think this requirement is met by the Widgets Signature document as it states The URI attribute must be a relative path to the root of the widget. how will this work with detached signatures where the widget content is not in the same context as the signature? [MP] I think there is still some confusion over the use case we're trying to address. There is no desire to complete the validation of the signature document before the widget package has been downloaded and therefore no need to use anything other than relative paths in the reference elements. The main motivation for providing the signature document in advance of the widget package is to allow the widget user agent to check whether it has the necessary root certs installed to validate the signature's cert chain. If the widget agent can't do this it may choose not to download the widget package. In some cases there may be an advantage to validating the signature value of the signature document in advance of downloading the widget package, noting that the entire signature document will not be validated until the reference validation has also been successfully completed. However, as stated on the call, it is not the intention to specify this use of the signature document in Widgets 1.0. As such the only requirement on the specification is that it does not rule out this use case, e.g. by specifying that reference validation must always happen before validation of the signature value. My understanding is that the current text is fine in this regards. Agreed. The above, theoretically, can already happen. The requirement just mandates that this will not change in the future. Kind regards, Marcos
Re: Comments on Widgets 1.0 Security requirements
Hi Frederick, Mark, On 1/7/09 6:36 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Some more discussion inline, thanks for taking the time to review. Do you mind updating the draft with the items we agree? regards, Frederick Frederick Hirsch Nokia On Jan 7, 2009, at 11:03 AM, ext Priestley, Mark, VF-Group wrote: Hi Frederick, Thanks for your comments. As someone who had a hand in some of the requirements that you've commented on, please see some responses inline. Regards, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Frederick Hirsch Sent: 05 January 2009 22:22 To: public-webapps Cc: Frederick Hirsch; Thomas Roessler Subject: Comments on Widgets 1.0 Security requirements I have some comments on requirements section 4.6, Security and DIgital Signatures, editors draft [1], and some concrete suggestions for changes: (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.- This requirement is unclear. Is the intent to say that a signature associated with a widget package might be extracted and served to a client independently of the package, allowing the package to be delivered without the signature inside of it? Or is it saying that the certificate chain and/or revocation information should be able to be accessed independently of the package? In general it might not make sense to validate a signature without access the widget content, since that is not meaningful unless it is possible to validate the content hashes used to generate and validate the signature. [MP] Re-reading the requirement I agree we could have been clearer in what we were requiring, which is: 1. It MUST be possible to extract a _copy_ of the digital signature document(s) from the widget package. 2. It SHOULD (MUST?) be possible for the widget user agent to complete the signature validation processing for a digital signature document that is provided independently of a widget package (noting that the signature is not validated until the reference validation processing has also been successfully completed) When we write the specification text to meet this requirement we will need to ensure that the error cases are covered, e.g. when the independently supplied and packaged digital signature do not match. With these clarifications hopefully the requirement and rationale make more sense? Although one can extract a signature XML element from a widget package, I'm not sure how meaningful that is if one cannot subsequently locate the content that is signed - for example if a ds:Reference refers to an item in the widget package, how can an extracted signature be validated if that item is no longer available? Along similar lines, I might expect the URI for a resource to be relative if the signature is always enveloped (the signature is within the widget package containing the signature and other items) but perhaps a full URL for detached, when the signature is stored separately from the signed items. I do not think this requirement is met by the Widgets Signature document as it states The URI attribute must be a relative path to the root of the widget. how will this work with detached signatures where the widget content is not in the same context as the signature? (2) R45 http://dev.w3.org/2006/waf/widgets-reqs/#r45.- It would be useful to add a sentence as to why SHA-1 is still required, e.g. Continued SHA-1 support is recommended to enable backward compatibility and interoperability. On the other hand if the widget specification has not yet been adopted, is there a reason not to require SHA-256 (and make SHA-1 optional), given the known potential weaknesses with SHA-1? Suggestion: replace MUST strongly recommend the use of SHA-256 to MUST recommend SHA-256 for new signature generation and must recommend SHA-1 and SHA-256 for signature verification (or explicitly note that SHA-1 is optional) strongly recommend is not a normative phrase according to RFC 2119. [MP] I support your suggested changes. I strongly suggest we require XML Signature 1.1 which should include new algorithms and address some practices around their use. I support this move. (3) R46 http://dev.w3.org/2006/waf/widgets-reqs/#r46.- Change and to or in the first sentence and or to and in the second to obtain the intended meaning. [MP] Well spotted, this is indeed an error - I support your suggested changes (4) R49 http://dev.w3.org/2006/waf/widgets-reqs/#r49.- The phrase To provide up-to-date is misleading, since cached information may be less up to date than the result of an online query, especially with OCSP. Suggest changing rationale paragraph to To enable a widget to obtain revocation information without having to query an online CRL or OSCP server from each device. This is a lot more efficient and eases
Re: Comments on Widgets 1.0 Security requirements
Hi Frederick, I've updated the requirements document wrt the suggestions you have made. However, I have not yet included the new requirements as I need to consider them a bit more before I do so. Naturally, if we find that things like expiration and policy association are applicable beyond widgets, I'm wondering if they should become requirements for XML Dig Sig 2.0? Inline comments below... On 1/5/09 10:21 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: I have some comments on requirements section 4.6, Security and DIgital Signatures, editors draft [1], and some concrete suggestions for changes: (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.- This requirement is unclear. Is the intent to say that a signature associated with a widget package might be extracted and served to a client independently of the package, allowing the package to be delivered without the signature inside of it? Or is it saying that the certificate chain and/or revocation information should be able to be accessed independently of the package? In general it might not make sense to validate a signature without access the widget content, since that is not meaningful unless it is possible to validate the content hashes used to generate and validate the signature. Simplified the requirement (see my response to Art). (2) R45 http://dev.w3.org/2006/waf/widgets-reqs/#r45.- It would be useful to add a sentence as to why SHA-1 is still required, e.g. Continued SHA-1 support is recommended to enable backward compatibility and interoperability. I've added the text above to the rationale. On the other hand if the widget specification has not yet been adopted, is there a reason not to require SHA-256 (and make SHA-1 optional), given the known potential weaknesses with SHA-1? Suggestion: replace MUST strongly recommend the use of SHA-256 to MUST recommend SHA-256 for new signature generation and must recommend SHA-1 and SHA-256 for signature verification (or explicitly note that SHA-1 is optional) strongly recommend is not a normative phrase according to RFC 2119. I reworded the requirement using your recommended text. (3) R46 http://dev.w3.org/2006/waf/widgets-reqs/#r46.- Change and to or in the first sentence and or to and in the second to obtain the intended meaning. Fixed. (4) R49 http://dev.w3.org/2006/waf/widgets-reqs/#r49.- The phrase To provide up-to-date is misleading, since cached information may be less up to date than the result of an online query, especially with OCSP. Agreed. Suggest changing rationale paragraph to To enable a widget to obtain revocation information without having to query an online CRL or OSCP server from each device. This is a lot more efficient and eases the load on CRL or OCSP servers. Note, however, that the revocation information may not be as up to date as an online query. However, if this information is updated at the server in a timely manner before widget installations, then an online query would not be necessary at the client. New rationale seems good. Added your text, but with some minor editorial changes. (5) Missing requirement: A signature should indicate the role of the signer. Suggested text A signature may be signed by a widget author as well as a widget distributor. The role of the signer should be indicated to enable the verifier to understand the role of the signer and associated implications. We have been bouncing the idea around of having an author.sig resource inside the package to overcome this issue. However, this is a more elegant solution. Again, would this be something useful for XML Dig Sig 2.0? (6) Missing requirement: A signature should indicate a policy associated with it, independent of information associated with key or certificate information For example, a signature should have a usage (or policy) property indicating that it is associated with the W3C Widget Signature specification and processing rules. The use of a URL is recommended to allow different policies and to enable updated versions. I support this requirement. Can you give me an (XML) example of what this might look like? (7) Missing requirement: Widget packages only require signature validation and certificate and revocation verification upon first installation on a device Proposed text: A widget package signature is validated and associated certificates and revocation information verified, only when the widget is first installed on the device. Signatures and certificate and revocation information may be updated over time at the server for subsequent installation on other devices, effectively creating a new widget package. This seems reasonable, tough a little like an implementation detail. However, I'm happy to include this requirement. (8) Missing requirement - Widget signatures must include counter- measures against use of out of date widget packages Since a signature is
Re: Next steps on Widgets testing?
Hi Dominique, On 11/25/08 2:05 PM, Dominique Hazael-Massieux d...@w3.org wrote: Hi Art, Charles, As was discussed during the WebApps WG F2F in Cannes, the Mobile Web Test Suites Working Group (and in particular, Kai Hendry) has started to work on developing test cases for the Widgets Packaging and Configuration specification: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0235.html There are already quite a number of test cases available there (~50), that target well-defined part of the specifications. Could you let our group know whether you think this is going in the right direction, and what the next steps should be on our side? This is going great. However, as the test suite is being built we would appreciate feedback from a specification verification perspective: are there assertions made that are not testable or that could be better written, and if there is much variability in the specification? These feedback is crucial for Web Apps if we are to improve the quality of our specifications. Unless you guys have a better way to do this, I would like to see the specification follow the CSS2.1 Test Case Authoring Guidelines (even if those guidelines are not complete). Also, would it be helpful if the tests were moved to the public CVS server? should they sit in 2006/waf/widgets/tests/ if so? The tests are now there. However, I think it makes more sense for if each spec had it's own test suite. For example, tests for Widgets 1.0: Digital Signatures would sit in 2006/waf/widgets-digsig/tests/, etc. Kind regards, Marcos
Re: Comments on Widgets 1.0 Security requirements
Hi Artb, On 1/13/09 7:46 PM, Arthur Barstow art.bars...@nokia.com wrote: I agree with Frederick that R44 as codified in the most recent ED (11 Dec 2008) isn't clear, particularly trying to foresee what exactly would be specified in the Widgets DigSig spec and assuring we don't prescribe deployments: [[ R44. Signature Document Independence http://dev.w3.org/2006/waf/widgets-reqs/#r44.- A conforming specification MUST recommend a digital signature format that allows for the signature value(s) and associated certificate chain(s) (if any) associated to the widget resource to be used independently of the widget resource. A conforming specification SHOULD provide guidelines for how any digital signature can be used separately from a widget resource. ]] Based on the following clarifications and Mark's reply above: [[ http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0036.html 1. It MUST be possible to extract a _copy_ of the digital signature document(s) from the widget package. 2. It SHOULD (MUST?) be possible for the widget user agent to complete the signature validation processing for a digital signature document that is provided independently of a widget package (noting that the signature is not validated until the reference validation processing has also been successfully completed) ]] It seems like #1 is a no-brainer in that every file in the package must be extractable and if that requirement needs to be explicit, it doesn't need to be stated as such in the context of Signature Document Independence. I view #2 as an implementation optimization that should be out-of- band for the spec. I can't imagine we would write a spec that would preclude a UA from doing what it is described above. Given all of this, I'm not convinced this requirement is needed. I agree with Art, this requirement is a no brainer. Nevertheless, I'm as it does not real harm, I'm inclined to leave it the document. I've renamed it and rewritten it as: [R44. Signature Document Format A conforming specification MUST recommend a digital signature format that can be extracted and used independently of the widget resource. A conforming specification SHOULD provide guidelines for how any digital signature can be used separately from a widget resource.] Kind regards, Marcos
FW: tag: uri scheme
Hi All, WebApps-WG recently asked Tim Kindberg, editor of the TAG URI scheme, if could make some comments about the widgets' requirements for a URI scheme. Below, Tim agrees that tag: is probably suitable for widgets, but raises some concerns about i18n and having a resolution algorithm to go from a tag: to a resource inside a widget. Kind regards, Marcos -- Forwarded Message From: Tim Kindberg timo...@hpl.hp.com Date: Wed, 17 Dec 2008 09:15:48 + To: Arthur Barstow art.bars...@nokia.com Cc: Argh marcosscace...@gmail.com, www-arch...@w3.org www-arch...@w3.org Subject: Re: Fwd: tag: uri scheme Hi Art, I've had a quick look through the resources you referenced. It does seem that tag: is a good candidate for your needs (although I have a couple of questions below). You need an id scheme that isn't quite matched by http etc., and it's better to avoid an entirely new scheme. My points are: (1) Don't you say you want internationalised ids? We (I) gave up on IRI-compatible tags some time ago. It's do-able but I got mired in the mud and ran out of time. (2) Somewhere I saw a reference to using a fixed date, 2008, for 'security reasons. Well that's OK as long as any domain name (or email address) that comes before it was indeed assigned to the minter of the tag on 2008-01-01. (3) From my glance at your documents, it seems that you need a resolution algorithm, to go from a tag: to a resource inside a widget. That's OK by the tag spec: there is no default resolution mechanism but any tag usage protocol can define its own. AFAIK, Atom 'id' elements (the biggest user of tag URIs) are chosen to be resolvable internally to feed generators. I hope that that is of some help, even though I've only had a little time to look at your requirements. I'm actually on leave until January now but may be able to respond occasionally in the meantime. Cheers, Tim. Arthur Barstow wrote: Hi Tim, I am a Chair of the W3C's Web Applications WG [WebApps] and in the context of our Widgets spec [Widgets], particularly Requirements #6 [Req-6] and #37 [Reg-37], we are interested in the tag: scheme. Marcos Caceres, the Editor of our Widgets spec, asked me to contact to you re this scheme. For a bit of context, please see his email below as well as a summary of the Widget scheme issue in [Widget- scheme]. If you have any info to share, we would greatly appreciate it. Here is one the latest discussion threads we've had on this scheme: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 0299.html -Regards, Art Barstow [WebApps] http://www.w3.org/2008/webapps/wiki/Main_Page [Widgets] http://dev.w3.org/2006/waf/widgets-reqs/ [Req-6] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing [Req-37] http://dev.w3.org/2006/waf/widgets-reqs/#r37.- [Widget-scheme] http://tinyurl.com/69yegh Begin forwarded message: From: ext Marcos Caceres marcosscace...@gmail.com Date: December 6, 2008 11:56:24 AM EST To: Arthur Barstow art.bars...@nokia.com Subject: tag: uri scheme Hi Art, I'm wondering if you could do me a huge favor. In light of the tag: uri scheme potentially meeting our needs in regards to a widget uri, I was wondering if you could take the time to contact Tim Kindberg (timo...@hpl.hp.com), who created the tag: scheme, and possibly ask him to weight in on the discussion on the packaging list, web apps list, and the TAG list. It would be great if you could point him to our requirements R6 and R37 and maybe some of the relevant emails. It would also be a big help if you could also ask him if he managed to resolve i18n issues with tag:; And if no, what would need to be done. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au -- Tim Kindberg hewlett-packard laboratories filton road stoke gifford bristol bs34 8qz uk purl.org/net/TimKindberg timo...@hpl.hp.com voice +44 (0)117 312 9920 fax +44 (0)117 312 8003 -- End of Forwarded Message
Re: Comments on Widgets 1.0 Security requirements
Hi Frederick, On Tue, Jan 20, 2009 at 4:23 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Requirements related to widgets should be clearly stated, even if mechanisms can be used beyond widgets. Thus if widgets need expiration then we should be able to articulate both the use case and the requirement. Agreed. We should probably discuss these requirements in this weeks teleconf and decide on which ones we are going to formally specify as part of Widgets 1.0 and which can be deferred to XML Dig Sig. Thanks for updating the requirements document for the other items. No problem. Thank you for providing the feedback and helping clarify the requirements! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widget Packaging and configuration LC review
Hi Benoit, Inline comments below. For the sake of the LC disposition of comments, please be sure to indicate if you are satisfied with the changes I have made On 1/20/09 8:50 PM, SUZANNE Benoit RD-SIRP-ISS benoit.suza...@orange-ftgroup.com wrote: Hello All, Here are some comments on the Jan 17th draft: 1.5 Global Definitions There are some misplaced quotes that could be deleted and I propose the more generic formulation: The [Widgets-Landscape] defines a widget as an end-user's conceptualization of an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine, mobile phone, or any Internet-enabled device. Because widgets are packaged, they can be liberally shared by users without relying on [HTTP] (i.e., users can share widgets over Bluetooth or through other distribution channels). Fixed. In addition with the defined words, we should also add the following: A User is the actual consumer of the widget content that the author has created. Added, but as end-user as that is the term that is used throughout the spec. A User Agent is the runtime environment in which a widget runs. It is also known as a widget engine. That definition of user agent is not broad enough to encompass conformance checkers. The definition you suggested is already covered by widget user agent. 6 Widget Resources In this section ther is a lot of references to ³localized folders² where the wording should be more specific as it is not just anywhere but at the root level of the righ local folder, therefore I propose the following edit: * One or more start files, located at the root of the widget or in the root of the language folders. I know that localized folder seems weird there because localized folder has not yet been defined when you get to that part of the document. I've added root of the. The formulation has also to be edited in the same way all throughout the rest of the document. There is a distinction between the localization folder (ie ³/Locales/²) and the language folder (ie ³/Locales/FR/²) The locales/ is defined as the container for localized content (there was a mistake in the definition). However, I would prefer not to change this. Instead, I've tighten up the definition of both localized folder and the container for localized content and added examples. Can you please check if it is more clear now. 6.5 Content Localization Author requirements: According to [BCP47], one should avoid region, script ... (unless there is a good reason to include them) as the a widget user agent... The ³a² seems to be a copy/paste edition leftover that should be deleted... Fixed. Localized Widget Example In order to cover tha various aspects, I belive this very good example should also include the following cases: * a script.js localization * a folder structure localization Therefore I propose to ad the /Locales/en-gb/scripts/engine.js file in this example with the related comments to explain the cases. I made your suggested change to /en-au/. 6.7 Custom Icons and Default Icons An icon must be located either at the root of the widget or in the root of the language folder. Same distinction as in section 6 fixed A default icon must be located either at the root of the widget or in the root of the language folder. Same distinction as in section 6 Fixed Default Icons In the table order I¹m not sure I understand why the png ad the gifs are not on top of the list. The reason that the table is structured that way is that the optional types are deemed to be more powerful then the required types: if the user agent supports SVG, which could be an interactive animated icon, it will select SVG first (rather then png or gif), and so on. PNG is also considered better than GIF, so it is selected before gif. 6.8 Thumbnail A thumbnail is an optional file inside the widget resource that graphically represents the widget in a running state. The thumbnail must be located either at the root of the widget or in the root of the language folder. Same distinction as in section 6 fixed. 7 Configuration Document Configuration documents can exist either at the root of the widget or in a the root of the language folder. Fixed. Note: Any configuration document not at the root of the widget or not in the root of the language folder will be treated by the widget user agent as an arbitrary resource. Fixed. Same distinction as in section 6 7.3 Attribute Types Window mode attribute A keyword attribute whose value is one of the following valid window modes: iconized, minimized, expanded, fullscreen and settings. I propose the following wording for the various modes: iconized, minimized, expanded, fullscreen and settings I would include some kind of attributes to the full screen to allow the determination of both
Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging Configuration spec; deadline 31 Jan 2009
. For example, consider an input element whose XML serialization looks like this: outerinner1First/inner1 inner2Second/inner2/outer The text content of this input, according to the spec's algorithm, is the the string FirstSecond. I would expect to get First Second as the text content in this case. Is there a reason to not just use textContent here? Note that even the example in the specification gets this wrong. There the markup is: name The blinkAwesome/blink author email=d...@example.comSuper blinkDude/blink/author Widget/name for which this algorithm gives The AwesomeSuper Dude Widget and not what the spec claims (I have also removed the carriage returns for legibility). True (see rewrite below). In the same algorithm, there's mention of the input's text nodes. This relationship is not defined in this specification or elsewhere. I assume you mean the text nodes which have input as their ancestor, right? The input is the element being processed. In the same algorithm, rule 4 doesn't make sense to me. What's position? Is it a character, or an index? Or something else? If you mean to say that input's nodeValue is to be appended to result, just say that. In the informative section following this algorithm, there is mention of getTextContent() DOM3 Java interface, whatever that is. I'm not sure why we need to drag Java into this. If we want to say something about the node's DOM3 textContent property, we should just say that, in my opinion. There's no language binding involved here; the property is defined in the relevant IDL and its definition is language-agnostic. Agreed. Ok, that section was totally screwed:) I've rewritten the the algorithm and added a new algorithm that normalizes the white space: ==Rules for Getting Text Content== The rules for getting text content are given in the following algorithm. The algorithm always returns a string, which may be empty. 1. Let input be the element to be processed. 2. If the widget user agent supports [ITS]: If the element has the dir attribute from the [ITS] namespace with a valid its:dir value, then process its text nodes in accordance to the [ITS] specification. 3. Return the value of the textContent [DOM3Core] property for input. ==Rules for Getting Text Content with Normalized White Space== The rules for getting text content with normalized white space are given in the following algorithm. 1. Let input be the element to be processed. 2. Let result be the result of applying the Rules for Getting Text Content to input. 3. In result, convert any sequence of one or more U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) or U+0009 CHARACTER TABULATION (tab) character into a single U+0020 SPACE. 4. If the first character in result is a U+0020 SPACE, remove the first character. 5. If the last character in result is a U+0020 SPACE, remove the last character. 6. Return result. I've used the Rules for Getting Text Content with Normalized White Space for elements where space characters are unwanted (i.e., name and author). 9) In the Rules for Removing Whitespace section in Section 8.2, Step 2 have the following language: While position doesn't point past the end of input and the character at position is not one of the space characters, append character to the end of result and let position become the character in input. Here character is a Unicode character the first and second time it's mentioned, and seems to be an integer the third time? Or something? If you're trying to say that the position should move to the next character in input, say that, please. Ok, turns out that the Rules for Removing White Space are not actually needed anywhere (and would have cause problems because 10 00 11 would have been interpreted as 100011 instead of an error). I rewrote the Rules for Parsing Non-Negative Integer skip space characters instead (as should have been in the first place, and as if defined in HTML5). Skipping white space is done as follows- note that space characters is defined elsewhere in the spec: 1. Let input be the string being parsed. 2. Let result have the value 0. 3. If the length of input is 0, return an error. 4. Let position be a pointer into input, initially pointing at the start of the string. 5. Let nextchar be the character in input at position. 6. If the nextchar is one of the space characters, increment position. If position is past the end of input, return an error. Otherwise, go to 5 in this algorithm. ...algorithm continues as was already defined. 10) Is there a reason to not have any JPEG images in the Image Identification Table in Section 8.2, Step 2? I would have thought widgets might wish to include such images. Added. Kind regards, Marcos [1] http://webblaze.cs.berkeley.edu/2009/mime-sniff/mime-sniff.txt -- Marcos Caceres http://datadriven.com.au
