Re: [widgets] ITS in Widgets
On Mon, Feb 22, 2010 at 10:59 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 22 Feb 2010, at 18:11, Marcos Caceres wrote: Dear i18n core, I'm writing on behalf of the Web Apps WG about the possibility of conducting a joint teleconference to discuss some issues with the ITS [1] features in the Widgets 1.0 Family of Specifications. Basically, we would like to discuss: 1. Moving ITS functionality out of the Widgets Packaging and Configuration specification to a separate specification. 2. Clarifying some aspects of how content that uses ITS functionality is processed, so to address an API issue that is discussed below. As you may recall, the WebApps WG collaborated with i18n to integrate ITS functionality into the Widgets Packaging and Configuration (PC) specification [2]: namely, the its:span element and its:dir attribute. We now have approximately 10 vendors claiming to implement PC. Unfortunately, we have not managed to get a single vendor to implement the ITS features; and, as far as we know, none of these implementations intend to implement the ITS features. As I understood it there is the its:span element and/or the its:dir attribute. Many PC elements can have an its:dir attribute, and we've implemented all of these though not yet all consistently. For example, if you set its:dir on license, then you'll get that info in the Wookie widget catalogue with ITS attribute, but we haven't ensured that the same is true for description and longname (though this mail has reminded me to go and fix it...) Hold up fixing anything, as we are moving to defining the ITS behavior in the PC spec. The its:span element is trickier as its an exception then to the general rules for processing content in PC and requires special handling as it would be the only case where markup is allowed inside content. This is correct. We are going to create a specification just for this case. We are hopefully going to work with the i18n WG to get this specified quickly. The lack of commitment by vendor's to support the ITS specification in the PC specification is blocking us from progressing the PC to Proposed Recommendation. We must state that this is not a criticism of ITS, and we are unclear as to why implementers are choosing not to support it. Vendors have indicated that they do, however, support the appropriate Unicode characters to control directionality. As we are fully committed to having a suitable i18n solution for PC, the Web Apps working group would like to co-ordinate with i18n to address this issue at the markup level. We want to discuss the creation of a new specification that would add the span/dir functionality in the widget namespace. We are only proposing this because various members (Opera included) have expressed that they would be more willing to implement the ITS functionality if it was defined in the widget namespace. The working group has also identified a potential issue with how ITS data is passed to one of our APIs [3]. The issue of accessing ITS marked-up content through an API is important, as currently if one has nameFoo span dir='rlt'esrever/span Bar/name, one gets a string back in the API that loses the direction information. The Web Apps Working Group believes that an orthogonal specification could address this issue. I think solving this issue may resolve others, as you then have a reason for parsing the ITS information correctly in the PC stage and can more readily demonstrate functionality for it. Agreed. Both the i18n WG and the Web Apps WG feel it would be better for authors if this was an integral part of the configuration document vocabulary. Dropping the its namespace is also helpful for authors and implementers. We hope that by making these changes we won't break existing implementations and will allow the dir attr and span element to be neatly included into the spec. -- Marcos Caceres http://datadriven.com.au
Fwd: Information about latest specs for language tagging
Editors, All - FYI, some information from the I18N group re normative reference for language tags. Begin forwarded message: From: ext Richard Ishida ish...@w3.org Date: March 1, 2010 9:53:20 AM EST Subject: Information about latest specs for language tagging It seems that a number of people are unaware of recent changes with regards to language tagging specifications. As it is important to use the right reference for spec development, I hope the following information will prove useful. You used to specify a language tag using RFC 1766, and then RFC 3066, both of which referred you to a list of ISO codes for language subtags and another ISO list for country names. RFC 3066 was replaced by two RFCs: 4646 (Tags for Identifying Languages) and 4647 (Matching of Language Tags). These two RFCs were concatenated at a single location under the name BCP 47. It is intended that BCP 47 will be an unchanging name with a single, unchanging URI that gives access to the most up-to-date RFCs as they are developed. This is particularly helpful since it is not clear from reading RFC the itself that it has been obsoleted. In September 2009, RFC 4646 was obsoleted by RFC 5646 (but RFC 4647 remains current). RFCs 5646 and 4647 are still referred to as BCP 47, and BCP 47 is accessed via the same URI as before. The latest specifications for language tagging allow a number of different types of subtag, over and above language and country/ region, and point you to the IANA Language Subtag Registry (rather than ISO code lists) to find the (almost 8,000) subtags which are now available for use. Any language tags constructed using the obsoleted RFCs are still valid according to the syntax of the latest incarnation of BCP 47, though some tags are now deprecated. We recommend that you currently use the following reference for language tag syntax. [BCP47] Tags for Identifying Languages, A. Phillips and M. Davis, Editors, September 2009. Available at http://www.rfc-editor.org/rfc/bcp/bcp47.txt The following additional links may be useful for further reading: IANA Language Subtag Registry http://www.iana.org/assignments/ language-subtag-registry Language tags in HTML and XML http://www.w3.org/International/ articles/language-tags/ Choosing a Language Tag http://www.w3.org/International/questions/ qa-choosing-language-tags Language Subtag Lookup tool http://rishida.net/utils/subtags/ If you have further questions about language tags, please contact the i18n WG. Hope that helps, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
Re: [widgets] dir and span elements
Hi Marcos, On 26 Feb 2010, at 17:44, Marcos Caceres wrote: Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET-BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] I can live with this, with a few comments: 1. dir is now an (optional?) attribute of every element; however, previously its usage was limited to elements that contain human- readable text content: author, license, description, and name. Is there a reason for making it global in this manner? E.g. would it not make more sense to specify dir attributes on these four specific PC elements? I don't see anyone putting dir on (e.g.) the height attribute, nor would we want to include a test for it for compliance with optional spec features. 2. span should be allowed as a child element of the license element as well as for name, description and author. Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
RE: [widgets] dir and span elements
Hi Scott, One reason to make 'dir' available on higher-level elements is that 'dir', like 'xml:lang', has scope. It is often useful to specify a base directionality for an entire document or block of elements rather than having to repeat it over-and-over on each affected element. I can agree that it might not make sense on every element and perhaps we should look at which structural elements in PC make sense as a place to set a base directionality or directionality override. I also agree about making span available inside license. In fact, it is probably the *most* useful inside the license element. Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. -Original Message- From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- requ...@w3.org] On Behalf Of Scott Wilson Sent: Monday, March 01, 2010 9:44 AM To: marc...@opera.com Cc: public-webapps; public-i18n-c...@w3.org Subject: Re: [widgets] dir and span elements Hi Marcos, On 26 Feb 2010, at 17:44, Marcos Caceres wrote: Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET- BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS- BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] I can live with this, with a few comments: 1. dir is now an (optional?) attribute of every element; however, previously its usage was limited to elements that contain human- readable text content: author, license, description, and name. Is there a reason for making it global in this manner? E.g. would it not make more sense to specify dir attributes on these four specific PC elements? I don't see anyone putting dir on (e.g.) the height attribute, nor would we want to include a test for it for compliance with optional spec features. 2. span should be allowed as a child element of the license element as well as for name, description and author. Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] dir and span elements
On 1 Mar 2010, at 17:58, Phillips, Addison wrote: Hi Scott, One reason to make 'dir' available on higher-level elements is that 'dir', like 'xml:lang', has scope. It is often useful to specify a base directionality for an entire document or block of elements rather than having to repeat it over-and-over on each affected element. I can agree that it might not make sense on every element and perhaps we should look at which structural elements in PC make sense as a place to set a base directionality or directionality override. Thanks Addison - and yes, I think this makes a lot of sense for a content-style spec like HTML, however as the Widgets PC is a configuration document most of which is IRIs, integers and so on rather than text content its less of a clear case. If dir conformance is tested in relation to the Rule For Obtaining Text Content then this already scopes its use to the four elements mentioned as these are the only elements that the rule applies to. I also agree about making span available inside license. In fact, it is probably the *most* useful inside the license element. Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. -Original Message- From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- requ...@w3.org] On Behalf Of Scott Wilson Sent: Monday, March 01, 2010 9:44 AM To: marc...@opera.com Cc: public-webapps; public-i18n-c...@w3.org Subject: Re: [widgets] dir and span elements Hi Marcos, On 26 Feb 2010, at 17:44, Marcos Caceres wrote: Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET- BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS- BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] I can live with this, with a few comments: 1. dir is now an (optional?) attribute of every element; however, previously its usage was limited to elements that contain human- readable text content: author, license, description, and name. Is there a reason for making it global in this manner? E.g. would it not make more sense to specify dir attributes on these four specific PC elements? I don't see anyone putting dir on (e.g.) the height attribute, nor would we want to include a test for it for compliance with optional spec features. 2. span should be allowed as a child element of the license element as well as for name, description and author. Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
Thanks for the pointers. I'm actually pretty sold on the general idea of promises, and my intuition is that there won't be a very big resource penalty for using an API like this rather than callbacks or what's currently specced. At the same time, it seems as though there isn't much of a standard in terms of the precise semantics and some of the techniques (such as optionally taking callbacks and not returning a promise if they are supplied) seems like a decent answer for pure javascript APIs, but maybe not as good for IDL and a standard like this. Do you guys have any recommendations for the precise semantics we'd use, if we used promises in IndexedDB? To get started, let me list what I'd propose and maybe you can offer counter proposals or feedback on what would or wouldn't work? Each method on a Request interface (the async ones in the spec) whose counterpart returns something other than void would instead return a Promise. The promises would only have a then method which would take in an onsuccess and onerror callback. Both are optional. The onsuccess function should take in a single parameter which matches the return value of the synchronous counterpart. The onerror function should take in an IDBDatabaseError. If the callbacks are null, undefined, or omitted, they're ignored. If they're anything else, we should probably either raise an exception immediately or ignore them. If there's an error, all onerror callbacks would be called with the IDBDatabaseError. Exceptions within callbacks would be ignored. In terms of speccing, I'm not sure if we can get away with speccing one promise interface or whether we'd need to create one for each type of promise. On Thu, Feb 18, 2010 at 4:20 PM, Kris Zyp k...@sitepen.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/18/2010 5:31 AM, Jeremy Orlow wrote: On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com mailto:k...@sitepen.com k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. Promises are heavily used in the E programming language, the Twisted project (python). In JavaScript land, Dojo's Deferred's are an example of a form of promises and a number of SSJS projects including Node and Narwhal. To see some examples, you can look at the Dojo's docs [1] (note that Dojo's spells it addCallback and addErrback instead of then, however we are looking to possibly move to the CommonJS promise for Dojo 2.0). Here is somewhat random example of module that uses Deferred's [2] [1] http://api.dojotoolkit.org/jsdoc/1.3/dojo.Deferred [2] http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/rpc/JsonRest.js I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Yes, that's exactly right, errors can be
RE: [widgets] dir and span elements
Thanks Addison - and yes, I think this makes a lot of sense for a content-style spec like HTML, however as the Widgets PC is a configuration document most of which is IRIs, integers and so on rather than text content its less of a clear case. No, I understand and don't disagree. However, there is something to be said for making it an attribute of widget, for example. Then you could have an override of directionality only when a given element has a different base direction. In the example in the spec [1], consider how this might be cleaner: widget dir=rtl name short=hard to make Arabic rtl here without changing enclosing element dir=ltr But ltr override here works fine. /name description Some rtl text. /description author href= email=bidi authors name/author license ... /license /widget Compared to: widget !-- no base direction -- name short=can't be rtl? dir=rtl Some RTL. /name description dir=rtl Have to include dir a lot. /description author dir=rtl ... /author license dir=rtl ... /license /widget I'm not suggesting that 'dir' makes sense everywhere, but there is some utility in allowing direction (and maybe language/locale??) in at the outermost element? If dir conformance is tested in relation to the Rule For Obtaining Text Content then this already scopes its use to the four elements mentioned as these are the only elements that the rule applies to. I agree, but there is one more potential case. The content element could have a default base directionality set (each content target or localized equivalent might also override it). I agree that a scoped 'dir' attribute is a pain to deal with implementation-wise, so I personally would be open to not doing this. But I think it worth considering. Addison [1] http://dev.w3.org/2006/waf/widgets/#example-configuration-document
Re: [IndexedDB] Lots of small nits and clarifying questions
On Mon, Mar 1, 2010 at 6:03 AM, Nikunj Mehta nik...@o-micron.com wrote: On Feb 28, 2010, at 3:24 PM, Jeremy Orlow wrote: Another nit: as far as I can tell, all of the common parts of the interfaces are named Foo, the synchronous API portion is FooSync, and the async API portion is FooRequest. This is true except for IndexedDatabase where the sync version is simply IndexedDatabase and the async version is IndexedDatabaseRequest. Can we please change IndexedDatabase to IndexedDatabaseSync for consistency, even though there is no common shared base class? I have no problems with renaming. However, before we go too much in to renaming, it is important to finalize the async API style. In general, I agree, but this was the one place where the naming seemed inconsistent, so I thought it was worth bringing up even with other large outstanding issues. You're right though that we do need to finalize the async API style. I've responded to [IndexedDB] Promises and will try to drive that to consensus soon. In the mean time, it'd be great if you (and others) could find the time to offer your opinions on the other issues I've brought up in both this and other threads (all with [IndexedDB] in the subject). J P.S. Would it be useful to accompany requests like this with a patch against Overview.html? That certainly helps. Attached. As far as I can tell, it's just a 2 liner, but maybe I missed something? On Thu, Feb 18, 2010 at 5:08 PM, Jeremy Orlow jor...@google.com wrote: I'm sorry that I let so much IndexedDB feedback get backlogged. In the future, I'll try to trickle things out slower. * * *Indexes:* 1) Creation of indexes really needs to be made more clear. For example, does creation of the index block everything until it's complete or does the database get created in the background? What if I have 1gb of my mail stored in IndexedDB and then a database migration adds an index? Is my app completely unusable during that time? What if the browser is exited half way through building (you can't just delete it)? What happens if you query the database while it's building in the background-building case (should it emulate it via entity-store-scans)? These are all very important questions whose answers should be standardized. 2) Why are Indexes in some database-global namespace rather than some entity-store-global namespace? I know in SQL, most people use the table name as a prefix for their index names to make sure they're unique. Why inherit such silliness into IndexedDB? Why not connect every index to a particular entity-store? 3) What happens when unique constraints are violated? 4) I don't remember anything explicitly stating that when a value changes that an index has a keypath referring to, that index should be updated. 5) It definitely would be nice to be able to index more than just longs and strings. 6) The specific ordering of elements should probably be specced including a mix of types. *Key ranges / cursors:* 1) Is an open or closed key range the default? 2) What happens when data mutates while you're iterating via a cursor? 3) In the spec, get and getObject seem to assume that only one element can be returned...but that's only true if unique is true. What do you do if there are multiple? 4) Why can the cursor only travel in one direction? 5) What if you modify a value that then implicitly (via the key-path) changes the index that your cursor is currently iterating over? *Transactions:* 1) We feel strongly that nested transactions should be allowed. Closed nested transactions should be simple to implement and will make it much easier for multiple layers of abstraction to use IndexedDB without knowledge of each other. 2) In the spec, dynamic transactions and the difference between static and dynamic are not very well explained. 3) I'm not sure that I like how the spec talks about commits being durable but then later says Applications must not assume that committing the transaction produces an instantaneously durable result. The user agent may delay flushing data to durable storage until an appropriate time. It seems like the language should be made more consistient. Also, it seems like there should be some way to ensure it is durable on disk for when it's absolutely necessary. (But maybe with a note that UAs are free to rate limit this.) *Misc:* 1) Structured clone is going to change over time. And, realistically, UAs won't support every type right away anyway. What do we do when a value is inserted that we do not support? 2) It seems that you can only be connected to one database at a time? If so, why? 3) Do we have enough distinct error codes? For example, there are multiple ways to get a NON_TRANSIENT_ERR when creating a transaction. Error strings can help with debugging, but they can differ between UAs. It seems as though all errors should be diagnosable via the error
