[widgets] Testing ITS support
Dear i18n WG, During the call to transition the Widgets Packaging and Configuration specification (PC) [1] to CR, the Director requested that aside from the MUST assertions the Web Apps WG test the optional aspects of the specification in our test-suite [2]. As you are aware, to facilitate the localization of text nodes within XML elements in a configuration document, a user agent may support the Internationalization Tag Set's its:span element and the its:dir attribute (It is optional for a user agent to support other ITS elements and attributes). In order to test ITS support, the WebApps WG would appreciate some guidance with designing a handful of test cases that the i18n WG would consider suitable to provide interoperability across implementations. The its:span element can be used as a child element of the following elements of the configuration document. In addition, the its:dir attribute can be used in the following elements of the configuration document: * name * description * author * license Any guidance or help the i18n WG can provide us with designing test would be greatly appreciated. We are intending to transition this document to Proposed Recommendation at the end of January, but we would like to have the i18n tests done ASAP. I'm happy to work on the tests, so long as someone from i18n can guide me :) Hope the i18n WG can again help us out! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets/ [2] http://dev.w3.org/2006/waf/widgets/test-suite/
Re: [widgets] test-suite, default xml:lang
Cyril Concolato a écrit : Hi all, I'm trying to understand the difference between two tests: [1] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/000/config.xml [2] http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/003/config.xml In [1], the first description element is supposed to be the valid one (it does not have an xml:lang attribute). In [2], the first description element as a dummy xml:lang that's not supposed to match anything. The second description element does not have the xml:lang attribute, but according to the expected result, it should not be the selected one. I don't understand why? Can you explain what the user locale should be in both cases? The test suite document indicates that it should be en. If this is the case, in [1] no description element shall match. Otherwise you probably want to indicate that some tests assumes * like [1] and others en like [2]. Am I wrong? Actually, I found a sentence that I missed in previous readings, which explains the difference between [1] and [2]: In the case whereby the author does not use an xml:lang attribute, and no element of a particular type with xml:lang matches the user agent locales, the user agent will use the first element that is unlocalized content, in document order, that matches the element type being sought. As a clarification can you tell me what would be the name value for the following config documents assuming the user locale is en only (no *) widget xmlns=http://www.w3.org/ns/widgets; name xml:lang=frA/name name xml:lang=krB/name name xml:lang=itC/name /widget My guess would be: widget xmlns=http://www.w3.org/ns/widgets; name xml:lang=frA/name name xml:lang=krB/name nameD/name name xml:lang=itC/name /widget My guess would be: D Am I correct? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: Selectors CR criteria
Sean Hogan wrote: What is the reason for the native implementation requirement? Is it W3C policy? There's a couple of reasons for this. The main reason being that JavaScript libraries are not limited by the same compatibility constraints as a browser, and so something that could be implemented in a JavaScript library without any problems may prove to have backwards compatibility issues with some legacy sites and affect a browser's ability to implement it. Basically, in this sense, a JS library is effectively a walled garden implementation where it's only used on sites that are explicitly built for it. So allowing such implementations to count effectively undermines the whole purpose of the implementation requirement, which is there to help demonstrate that the spec works in practice. The other reason is that it's not always technically possible for a JS library to implement all the required functionality due to the limitations of the DOM, or at least some implementations of it. For example, it's not possible in IE to add the methods to the prototypes for the Document, Element or DocumentFragment nodes. Also, in practice, implementations like in JQuery don't actually try to implement the methods themselves. They just implement somewhat compatible functionality and expose it on their own objects (e.g. $(divp); instead of document.querySelector(divp);). -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] Testing ITS support
Hello Marcos, in case you are also aiming at support for other ITS elements and attributes: you could adapt the following tests from the ITS test suite http://www.w3.org/International/its/tests/ which the ITS Working Group used for attributes at the its:span element. TRANSLALTE Local - In its:span Sourcehttp://www.w3.org/International/its/tests/inputdata/Translate3.xml Resulthttp://www.w3.org/International/its/tests/expected/Translate3-result.xml Resulthttp://www.w3.org/International/its/tests/test1/Translate3-result.xml Resulthttp://www.w3.org/International/its/tests/test2/Translate3-result.xml Resulthttp://www.w3.org/International/its/tests/test3/Translate3-result.xml LOCALIZATION NOTE Local - In its:span with mixed notes Sourcehttp://www.w3.org/International/its/tests/inputdata/LocNote4.xml Resulthttp://www.w3.org/International/its/tests/expected/LocNote4-result.xml Result http://www.w3.org/International/its/tests/test1/LocNote4-result.xml Result http://www.w3.org/International/its/tests/test2/LocNote4-result.xml Result http://www.w3.org/International/its/tests/test3/LocNote4-result.xml TERMINOLOGY Local - In its:span Sourcehttp://www.w3.org/International/its/tests/inputdata/Terminology4.xml Resulthttp://www.w3.org/International/its/tests/expected/Terminology4-result.xml Resulthttp://www.w3.org/International/its/tests/test1/Terminology4-result.xml Resulthttp://www.w3.org/International/its/tests/test2/Terminology4-result.xml Resulthttp://www.w3.org/International/its/tests/test3/Terminology4-result.xml As you can see from the results, the implementation just has to be able to make the ITS information available for further processing. So if you have build three similar tests for these ITS data categories and one for directionality (see Richards pointer), you are done IMO. Best, Felix 2009/11/27 Marcos Caceres marc...@opera.com Dear i18n WG, During the call to transition the Widgets Packaging and Configuration specification (PC) [1] to CR, the Director requested that aside from the MUST assertions the Web Apps WG test the optional aspects of the specification in our test-suite [2]. As you are aware, to facilitate the localization of text nodes within XML elements in a configuration document, a user agent may support the Internationalization Tag Set's its:span element and the its:dir attribute (It is optional for a user agent to support other ITS elements and attributes). In order to test ITS support, the WebApps WG would appreciate some guidance with designing a handful of test cases that the i18n WG would consider suitable to provide interoperability across implementations. The its:span element can be used as a child element of the following elements of the configuration document. In addition, the its:dir attribute can be used in the following elements of the configuration document: * name * description * author * license Any guidance or help the i18n WG can provide us with designing test would be greatly appreciated. We are intending to transition this document to Proposed Recommendation at the end of January, but we would like to have the i18n tests done ASAP. I'm happy to work on the tests, so long as someone from i18n can guide me :) Hope the i18n WG can again help us out! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets/ [2] http://dev.w3.org/2006/waf/widgets/test-suite/
Re: [widgets] about test d1.wgt
Hi Cyril,
Cyril Concolato wrote:
Hi Marcos,
Marcos Caceres a écrit :
Hi Cyril,
On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato
cyril.concol...@enst.fr wrote:
Hi,
The test d1.wgt is about the src attribute of the icon element. It
says that
it tests the following assertion:
If the src attribute of this icon element is absent, then the user
agent
must ignore this element.
but the config.xml contains an src attribute with an empty value.
This seems
a bit different to me. Maybe you should modify the spec as follows:
If the src attribute of this icon element is absent *or empty*, then
the
user agent must ignore this element.
Ok, your are totally right (sorry, I didn't get it the first time!). A
clarification was needed there and I've added it (or an empty string
was needed in the spec).
I've made two tests:
test-suite/test-cases/ta-iipTwNshRg/000/d1.wgt (absent)
test-suite/test-cases/ta-iipTwNshRg/001/ga.wgt (empty)
{Robin: you might want to retest, but I'm sure Widgeon passes}.
Well, you get the same result when you actually search for the file
, as it won't be found. But I agree, a simple clarification there
won't actually hurt or change the ways UAs work at the moment.
Also you should make sure the tests are aligned between the icon
element and
the content element. There does not seem to be such test with the
content
element. If you make such test, you should also align the spec in the
same
manner.
I'm not sure I understand, can you design the test to show what you
mean. I can then add it to the test suite.
I meant that there is test like:
widget xmlns=http://www.w3.org/ns/widgets;
icon src=/
/widget
but no test like:
widget xmlns=http://www.w3.org/ns/widgets;
content src= /
/widget
I've added a test for this too:
test-suite/test-cases/ta-LTUJGJFCOU/002/gb.wgt (empty src)
Re: [widgets] Testing ITS support
On Nov 27, 2009, at 5:14 AM, ext Marcos Caceres wrote: to test ITS support, the WebApps WG would appreciate some guidance with designing a handful of test cases that the i18n WG would consider suitable to provide interoperability across implementations. Please make sure the PC test suite does not include any test cases that overlap test cases created for ITS. -Art Barstow
[widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
This is a Call for Consensus (CfC) to publish Last Call Working Draft #2 of: http://dev.w3.org/2006/waf/widgets-access/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is December 2. For some additional background on this proposal, see: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0947.html -Art Barstow
[widgets] editing problem
Hi Marcos, Reading the rule for identifying the media type of a file in the editor's draft [1], I think there is an editing problem. The first 4 bullets are numbered (1,2,3,4) and rest of the bullets are not which makes the algorithm refer to step 10 and 11 that don't exist. Regards, Cyril [1] http://dev.w3.org/2006/waf/widgets/#rule-for-identifying-the-media-type-of-a0 -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
RE: [widgets] editing problem
Hi, I assumed it was corrected with this email: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0828.html Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Cyril Concolato Sent: Friday, November 27, 2009 3:44 PM To: public-webapps Subject: [widgets] editing problem Hi Marcos, Reading the rule for identifying the media type of a file in the editor's draft [1], I think there is an editing problem. The first 4 bullets are numbered (1,2,3,4) and rest of the bullets are not which makes the algorithm refer to step 10 and 11 that don't exist. Regards, Cyril [1] http://dev.w3.org/2006/waf/widgets/#rule-for-identifying-the-media-type-of-a0 -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] Testing ITS support
Arthur Barstow wrote: On Nov 27, 2009, at 5:14 AM, ext Marcos Caceres wrote: to test ITS support, the WebApps WG would appreciate some guidance with designing a handful of test cases that the i18n WG would consider suitable to provide interoperability across implementations. Please make sure the PC test suite does not include any test cases that overlap test cases created for ITS. Yes, there are currently no tests that overlap. However, tests are needed to explicitly test ITS within the context of a config document (specifically, that it works in the appropriate elements and is handled correctly in contexts where it is not expected). Kind regards, Marcos
Re: [widgets] editing problem
On Fri, Nov 27, 2009 at 3:59 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi, I assumed it was corrected with this email: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0828.html Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Cyril Concolato Sent: Friday, November 27, 2009 3:44 PM To: public-webapps Subject: [widgets] editing problem Hi Marcos, Reading the rule for identifying the media type of a file in the editor's draft [1], I think there is an editing problem. The first 4 bullets are numbered (1,2,3,4) and rest of the bullets are not which makes the algorithm refer to step 10 and 11 that don't exist. Woops! fixed. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] element-based localization
On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi, I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Then, many other elements (author, preference, icon, content ...) don't list this attribute and are not localizable but they can inherit the value of this attribute. This is correct, the are inherited but it has not effect because of the way elements are gathered in step 7: [[ For each range in the user agent locales, starting from the first and moving to the last: If the value of range is not *, then retaining document order, let matching elements be the result of applying lookup to the child elements of type name, description, and license that are direct descendents of the root element and whose xml:lang attribute matches the current range. Append matching elements to the element list. If the value of range is *, retaining document order, let unlocalized elements be all child elements that are direct descendents of the root element that do not have an implicit or explicit xml:lang attribute (i.e., match unlocalized content). Append unlocalized elements to the element list. ]] The rest of the elements may have the attribute specified or inherited and use it for localization. Correct. The paragraph explaining this behavior says: If an element is marked as being localizable via xml:lang with the word no, it means that the element is not localizable via element-based localization. In other words, exclusion of an xml:lang on an element indicates that that element is unlocalized content, except in the case whereby a parent element uses xml:lang (this maintains consistency with the behavior of xml:lang as specified in the [XML] specification). Explicitly declaring xml:lang overrides any xml:lang value inherited from a parent element. I think this paragraph (especially the last 2 sentences) are unclear. I would propose that you clarify as follows: I agree... As per [XML] specification, the xml:lang attribute can be specified on any element, including in the widget namespace, and the normal behavior for this attribute shall be applied (i.e. inheritance processing, and propagation of the xml:lang attribute on elements on which it is not specified). However, in this specification, the value of the xml:lang attribute (inherited or specified) shall be used for element-based localization only on the elements that indicates Localizable via xml:lang: Yes. I agree with text above. I think we should include it (with a few insignificant stylistic changes - see below). It's more precise than what is currently there and clears up the ambiguity that Cyril has identified. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I would also like to change add the following clarification to widget elements xml:lang attribute: Using this attribute causes all child elements to inherit this attribute and its value (as is the standardized behavior for the xml:lang specified in the [XML] specification). However, inheritance of the value of this attribute by author, preference, icon, and content has no effect during processing in Step 7 (i.e., elements that are explicitly marked as Localizable via xml:lang: no in this specification will be treated as if xml:lang had not been inherited or otherwise used). WDYT? I would also propose to remove the definition of the xml:lang attribute such as: xml:lang Authoring Guidelines:It is optional for authors to use the xml:lang attribute with an name element. because even if not written, XML allows specifying this attribute on any element. The only reason I would keep these is that they serve as a good authoring guides (saves authors and those trying to
Re: [widgets] element-based localization
Hi Cyril, I think we also need to clarify what happens when xml:lang=, in that it must be treated as unlocalized content e.g. widget xmlns=http://www.w3.org/ns/widgets; xml:lang=en name short=I'm in english, though not explicitly marked as such! Behaves as if xml:lang=en /name name xml:lang=pt The declaration of xml:lang=pt overrides xml:lang=en inherited from the widget element. /name name xml:lang= I am unlocalized content. /name /widget On Fri, Nov 27, 2009 at 8:55 PM, Marcos Caceres marc...@opera.com wrote: On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi, I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Then, many other elements (author, preference, icon, content ...) don't list this attribute and are not localizable but they can inherit the value of this attribute. This is correct, the are inherited but it has not effect because of the way elements are gathered in step 7: [[ For each range in the user agent locales, starting from the first and moving to the last: If the value of range is not *, then retaining document order, let matching elements be the result of applying lookup to the child elements of type name, description, and license that are direct descendents of the root element and whose xml:lang attribute matches the current range. Append matching elements to the element list. If the value of range is *, retaining document order, let unlocalized elements be all child elements that are direct descendents of the root element that do not have an implicit or explicit xml:lang attribute (i.e., match unlocalized content). Append unlocalized elements to the element list. ]] The rest of the elements may have the attribute specified or inherited and use it for localization. Correct. The paragraph explaining this behavior says: If an element is marked as being localizable via xml:lang with the word no, it means that the element is not localizable via element-based localization. In other words, exclusion of an xml:lang on an element indicates that that element is unlocalized content, except in the case whereby a parent element uses xml:lang (this maintains consistency with the behavior of xml:lang as specified in the [XML] specification). Explicitly declaring xml:lang overrides any xml:lang value inherited from a parent element. I think this paragraph (especially the last 2 sentences) are unclear. I would propose that you clarify as follows: I agree... As per [XML] specification, the xml:lang attribute can be specified on any element, including in the widget namespace, and the normal behavior for this attribute shall be applied (i.e. inheritance processing, and propagation of the xml:lang attribute on elements on which it is not specified). However, in this specification, the value of the xml:lang attribute (inherited or specified) shall be used for element-based localization only on the elements that indicates Localizable via xml:lang: Yes. I agree with text above. I think we should include it (with a few insignificant stylistic changes - see below). It's more precise than what is currently there and clears up the ambiguity that Cyril has identified. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I would also like to change add the following clarification to widget elements xml:lang attribute: Using this attribute causes all child elements to inherit this attribute and its value (as is the standardized behavior for the xml:lang specified in the [XML] specification). However, inheritance of the value of this attribute by author, preference, icon, and content has no effect during
Re: [widgets] test suite, duplicated test
On Fri, Nov 27, 2009 at 2:28 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, I noticed that the following two tests are the same (minimal config.xml). Maybe one of them should be removed or modified. Yes, the content of both test's XML files is the same, but they are testing different things (details below). http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-xGYcVTMoAX/000/ds.wgt This one tests: Tests that the user agent correctly sets the configuration defaults. To pass, author email must be null, author href must be null, author name must be null, feature list must be empty (null), icons must be null, start file encoding must be UTF-8, start file content-type must be text/html, widget config doc must be 'config.xml' at the root of the widget package, widget description must be null, widget height must be null, widget id must be null, widget license must be null, widget license file must be null, widget license href must be null, widget name must be null, widget preferences must be null, widget short name must be null, widget version must be null, widget width must be null, widget window modes must be an empty list, widget start file must be index.htm at the root of the widget, user agent locales must contain at least one item whose value is 'en' http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-MFcsScFEaC/000/d3.wgt This one tests: Test the UA's ability to progress to Step 8 when it has nothing to process inside the widget element. To pass, the widget start file must be index.htm Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
