Nabble - w3.org - public-webapps

[widgets] test-cases for icons: some possible errors

2009-11-29T09:03:53Z

Some more potential test case errors and fixes:

======
bl.wgt

✔ Tests the UA's ability to locate an icon in a locale folder and at
the root of the widget. To pass, after processing, the icons list must
contain a pointer to "locales/en/icon.jpg", and "icon.png", which is
at the root of the widget. The icons list needs to be in the correct
order, where "locales/en/icon.jpg" must be first and "icon.png" must
be second.

Following Step 9 and using "Rule for Finding a File Within a Widget
Package" I always get these the other way around, as "icon.png" is in
front of "icon.jpg" in the default icons list

======
bm.wgt

✔ Tests the UA's ability to deal with custom icon declaration in the
config document and matching default icons. To pass, the icons list
must contain a pointer to "locales/en/icon.jpg" and "icon.png", which
is at the root of the widget. The list needs to be in the correct
order, where "locales/en/icon.jpg" must be first and "icon.png" must
be second.

Following Step 9 and using "Rule for Finding a File Within a Widget
Package" I always get these the other way around, as "icon.png" is in
front of "icon.jpg" in the default icons list

======

bn.wgt

"✔ Tests the UA's ability to deal with custom icon declarations in
the config document and matching default icons. To pass, the icons
list must contain a pointer to "icons/pass.png", and "icon.png", which
is at the root of the widget. The list needs to be in the correct
order, where "icons/pass.png" must be first, followed by "icon.png".

As "{root}/icon.png" doesn't exist I think this should instead be

✔ Tests the UA's ability to deal with custom icon declarations in the
config document and matching default icons. To pass, the icons list
must contain a pointer to "icons/pass.png", and "locales/en/icon.png",
which is at the root of the widget. The list needs to be in the
correct order, where "icons/pass.png" must be first, followed by
"locales/en/icon.png".

======

bp.wgt

✔ Test the UA's ability to load default icons in the correct order.
To pass, the icons list must contain a pointer "icon.png" followed by
a pointer to "en/locales/icon.jpg".

Looks like a typo; I think this should instead be:

✔ Test the UA's ability to load default icons in the correct order.
To pass, the icons list must contain a pointer "icon.png" followed by
a pointer to "locales/en/icon.jpg".

======

zz.wgt

✔ Tests the ability of the user agent to correctly deal with an icon
element that points to a file that is not present in the widget
package. To pass, the icon list must contain "pass.png".

I don't think this is correct - either the package needs to include
the file "icon.png" and that gets in the list, or the list needs to be
empty, as there is no rule that identifies "pass.png" is a valid icon
when its not specified as a custom icon.

smime.p7s (3K) Download Attachment

Re: [widgets] Test suite full coverage of mandatory aspects in the P&C spec, was Re: OMTP BONDI Reference Implementation fully compliant against mandatory P&C tests

2009-11-28T15:22:54Z

Hi,

On 28 Nov 2009, at 22:36, Marcos Caceres wrote:

I am hopeful that other implementers will work with the WG to achieve
interoperability across the widget specs by providing us with test
suite results and means of verifying those results (and helping us
improve the test suite). I'll be moving the implementation report [1]
to the W3C on Monday (and I'll add the Widgeon tests).

We've implemented the test suite as part of the included automated tests for Apache Wookie [1], so you can easily verify for yourselves how we are doing by downloading Wookie [2] and running src-tests/org/apache/wookie/tests/conformance/PackagingAndConfiguration.java using JRun4.

We're working our way towards full conformance; so far we're passing 91 of the tests. If anyone would like to help us pass the remaining ones, please visit our tracker [3] and submit your patches!

-S

[1] http://incubator.apache.org/wookie/

[2] http://incubator.apache.org/wookie/downloading-and-installing-wookie.html

[3] http://issues.apache.org/jira/browse/WOOKIE

smime.p7s (3K) Download Attachment

[widgets] Test suite full coverage of mandatory aspects in the P&C spec, was Re: OMTP BONDI Reference Implementation fully compliant against mandatory P&C tests

2009-11-28T14:36:24Z

Hi,

On Sat, Nov 28, 2009 at 9:05 PM, David Rogers <david.rogers@...> wrote:
> Dear all,
>
> I am very pleased to be able to announce that OMTP's BONDI Reference
> Implementation for Windows Mobile is now fully compliant to the 165
> mandatory tests available for the W3C Widgets 1.0: Packaging and
> Configuration specification (proposed for CR #2). The test results can be
> found here:
> http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html

Congrats to the BONDI team :)

> Many thanks to Toby Ealden, Christian Breitschwerdt and Marcos Caceres for
> their outstanding efforts on this. We look forward to working with you all
> on having another interoperable implementation to help achieve full release
> of the specification.

Just wanted to add that last Friday I added the last remaining tests
to give us full coverage of all the MUST assertions in the P&C test
suite. There may be some tests we need to add in the future, but, as
editor, I am generally satisfied with the level of coverage we
currently have.

As noted in another email [2], we still need to add the optional tests
to allow us to progress to PR (as requested by the Director of the
W3C... again, any help with these tests is greatly appreciated).

I am hopeful that other implementers will work with the WG to achieve
interoperability across the widget specs by providing us with test
suite results and means of verifying those results (and helping us
improve the test suite). I'll be moving the implementation report [1]
to the W3C on Monday (and I'll add the Widgeon tests).

Also, Opera has released it's first set of test results for our
internal implementation currently as part of [1]. We have no date yet
as to when this implementation will be publicly available, however.

Kind regards,
Marcos

[1] http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0998.html

--
Marcos Caceres
http://datadriven.com.au

OMTP BONDI Reference Implementation fully compliant against mandatory P&C tests

2009-11-28T12:05:37Z

OMTP BONDI Reference Implementation fully compliant against mandatory P&C tests

Dear all,

I am very pleased to be able to announce that OMTP's BONDI Reference Implementation for Windows Mobile is now fully compliant to the 165 mandatory tests available for the W3C Widgets 1.0: Packaging and Configuration specification (proposed for CR #2). The test results can be found here: http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html

Many thanks to Toby Ealden, Christian Breitschwerdt and Marcos Caceres for their outstanding efforts on this. We look forward to working with you all on having another interoperable implementation to help achieve full release of the specification.

Please let me know if you have any comments or questions.

Thanks,

David.

David Rogers
OMTP Director of External Relations

Re: The most basic File API use case

2009-11-28T09:45:58Z

On Sat, Nov 28, 2009 at 11:38 AM, Nikunj R. Mehta <nikunj.mehta@...> wrote:

On Nov 20, 2009, at 1:37 PM, Peter O. Ussuri wrote:

Hello!

This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to illustrate some kind of expansion of existing browser capabilities, with ensuing discussion of potential new security risks. However, there is one quite general use case that is very unlikely to introduce any additional security issues and that is easy for everybody to understand (and for browser vendors to implement).

I would like to suggest a "Group 0" File API use case, in Eric's terminology.
Basically, there should be a way to do in JavaScript everything most browsers currently in use (including IE6) do without server round-trip. In the most general terms, it is currently possible, and relatively secure, to let the user select a file for upload, upload it to the server, do arbitrary processing, and then download/save the (new/modified) file back onto the user's local file system.

The current File API draft lets a web app to read the file, but there seems to be no easy way for a web app to construct an arbitrary binary file and trigger a SaveAs/download dialog, with the file name suggested by the app.

There is currently a way to do so being defined in the DataCache API [1]. The API provides for ways to generate a response payload, just like any http server could upon receiving an HTTP request. So you could insert a link with some URL on the page and register an offline handler for that URL. When the user clicks on that URL, it will call a DataCache interceptor, which is basically a JS function, to produce a response. If the MIME type of the generated response requires browser to use an external app, then it could easily spawn a file save/application open dialog just like in the case of file downloads.

Hi Nikunj, I checked DataCache API, but I could find no way to prepare arbitrary binary responses, only DOMStrings as responses. What if I want to, let's say, remove red eyes on a photo? I do need a way to prepare binary responses.

Another issue: what if I want to download/save a file with a MIME type that is "internal", like a picture, or a text file? I guess I'll need to set a header for that. And what about popup-blockers now active most of the time? Another issue: even if the download dialog is triggered, an empty window is left open in some browsers (I am actually using this solution with Google Gears API, so I see all these side-effects).

A direct saveAsDialog method is more robust and easier to use - using DataCache API, even if all the issues mentioned above can be worked through, is a work-around (clicking on a link should not be necessary).

The main idea here is to allow a "rich" client to be at least as functional as a "poor" html+server app is (w/o any dynamic client-side scripting). By recognizing this most basic use case, it will probably be easier to agree on the first iteration of FileWriter api, as most security issues have already been fleshed out.

Required api is quite simple to define and implement: a file builder (similar to BlobBuilder in Google Gears), and a "SaveAs" method that takes "pre-built" files (blobs). And later this basic API can be extended to introduce an event model and cover more advanced use cases.

Nikunj
http://o-micron.blogspot.com

[1] http://www.w3.org/TR/DataCache/

Re: The most basic File API use case

2009-11-28T08:38:57Z

On Nov 20, 2009, at 1:37 PM, Peter O. Ussuri wrote:

Hello!

This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to illustrate some kind of expansion of existing browser capabilities, with ensuing discussion of potential new security risks. However, there is one quite general use case that is very unlikely to introduce any additional security issues and that is easy for everybody to understand (and for browser vendors to implement).

I would like to suggest a "Group 0" File API use case, in Eric's terminology.
Basically, there should be a way to do in JavaScript everything most browsers currently in use (including IE6) do without server round-trip. In the most general terms, it is currently possible, and relatively secure, to let the user select a file for upload, upload it to the server, do arbitrary processing, and then download/save the (new/modified) file back onto the user's local file system.
The current File API draft lets a web app to read the file, but there seems to be no easy way for a web app to construct an arbitrary binary file and trigger a SaveAs/download dialog, with the file name suggested by the app.

There is currently a way to do so being defined in the DataCache API [1]. The API provides for ways to generate a response payload, just like any http server could upon receiving an HTTP request. So you could insert a link with some URL on the page and register an offline handler for that URL. When the user clicks on that URL, it will call a DataCache interceptor, which is basically a JS function, to produce a response. If the MIME type of the generated response requires browser to use an external app, then it could easily spawn a file save/application open dialog just like in the case of file downloads.

The main idea here is to allow a "rich" client to be at least as functional as a "poor" html+server app is (w/o any dynamic client-side scripting). By recognizing this most basic use case, it will probably be easier to agree on the first iteration of FileWriter api, as most security issues have already been fleshed out.
Required api is quite simple to define and implement: a file builder (similar to BlobBuilder in Google Gears), and a "SaveAs" method that takes "pre-built" files (blobs). And later this basic API can be extended to introduce an event model and cover more advanced use cases.

Nikunj

http://o-micron.blogspot.com

[1] http://www.w3.org/TR/DataCache/

Re: CfC - publish Selectors API as CR

2009-11-27T20:17:26Z

On Nov 26, 2009, at 6:05 AM, Lachlan Hunt wrote:

> Maciej Stachowiak wrote:
>>> The proposed exit criteria are in a separate thread, but
>>> essentially are:
>>>
>>> For a set of tests based on HTML, CSS 2.1 selectors and this spec,
>>> there are two implementations that pass every test interoperably,
>>> and
>>> do not fail any "additional" tests based on misimplementing this
>>> specification (i.e. failures based on not supporting a technology
>>> used
>>> only in the additional tests, such as MathML, will not be taken into
>>> account).
>>
>> Request for clarification. Does this require:
>>
>> A) There must be two implementations, each of which passes every test
>> (i.e. the same two implementations pass all the tests); or
>> B) For each test, there are two implementations that pass it (but not
>> necessarily the same two for every test).
>>
>> It reads like (A), but I have seen similar wording interpreted as
>> (B) in
>> the context of other specs...
>
> The intention in the original exit criteria proposal [1] was for
> there to be at least two complete implementations, each passing 100%
> of the baseline tests. I can make this clearer in the exit criteria
> as follows:
>

The wording below seems very clear and unambiguous to me. Thanks.

- Maciej

> ---
>
> There must be at least two complete, independent implementations,
> each of which must pass 100% of the baseline testsuite and should
> pass additional tests, dependent on the following conditions:
>
> * The implementations must be native implementations in shipping
> products. (JavaScript library implementations don't count).
>
> * The baseline testsuite comprises tests that check for conformance to
> all requirements in the API using only HTML and Selectors defined in
> CSS 2.1.
>
> * Tests using Selectors introduced in Selectors Level 3, or XHTML+SVG,
> are considered to be additional tests.
>
> * An additional test may be marked as N/A for an implementation if:
> - The test uses a selector that the implementation does not support
> - The test uses XHTML+SVG that the implementation does not support
>
> * Implementations are not required to pass all additional tests,
> however no failures must be caused by an incorrect implementation of
> the API itself. Failures of additional tests caused only by an
> incorrect implementation of Selectors do not count.
>
> ---

Re: [widgets] test suite, duplicated test

2009-11-27T12:17:35Z

On Fri, Nov 27, 2009 at 2:28 PM, Cyril Concolato
<cyril.concolato@...> 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

Re: [widgets] element-based localization

2009-11-27T12:13:26Z

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 <marcosc@...> wrote:

> On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato
> <cyril.concolato@...> 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 understand the
> spec from reading Step 7... which is by no means light reading! :) ).
>
>> Finally, I would also create some tests in the test-suite to check that
>> inheritance is applied and used or not depending on the element type.WDYT?
>
> I think it is a good idea to create tests for this. If you have
> created some already, please send them to me off-list and I will add
> them. I'm happy to discuss further what form these tests should take.
>
>
> --
> Marcos Caceres
> http://datadriven.com.au
>

--
Marcos Caceres
http://datadriven.com.au

Re: [widgets] element-based localization

2009-11-27T11:55:50Z

On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato
<cyril.concolato@...> 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 understand the
spec from reading Step 7... which is by no means light reading! :) ).

> Finally, I would also create some tests in the test-suite to check that
> inheritance is applied and used or not depending on the element type.WDYT?

I think it is a good idea to create tests for this. If you have
created some already, please send them to me off-list and I will add
them. I'm happy to discuss further what form these tests should take.

--
Marcos Caceres
http://datadriven.com.au

Re: [widgets] test-suite, default xml:lang

2009-11-27T10:39:00Z

On Fri, Nov 27, 2009 at 11:29 AM, Cyril Concolato
<cyril.concolato@...> wrote:

> 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="fr">A</name>
> <name xml:lang="kr">B</name>
> <name xml:lang="it">C</name>
> </widget>
>
> My guess would be: ""

Your guess would be correct. If no match is made and there is no
localized content, then there is no match.

> <widget xmlns="http://www.w3.org/ns/widgets">
> <name xml:lang="fr">A</name>
> <name xml:lang="kr">B</name>
> <name>D</name>
> <name xml:lang="it">C</name>
> </widget>
>
> My guess would be: "D"
>
> Am I correct?

Again, you are correct. I believe we have a test for that:

http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-VdCEyDVSA/005/config.xml

I guess it would be of value to add another example or two in the
spec. I will do that when we go to PR.

Thanks again for the feedback and for helping us improve both the spec
and the test suite! Sorry there are bits that are a bit ambiguous -
keep the feedback coming so we can fix that!:)

--
Marcos Caceres
http://datadriven.com.au

Re: [widgets] editing problem

2009-11-27T08:57:50Z

On Fri, Nov 27, 2009 at 3:59 PM, Marcin Hanclik
<Marcin.Hanclik@...> 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.hanclik@...
>
> -----Original Message-----
> From: public-webapps-request@... [mailto:public-webapps-request@...] 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] Testing ITS support

2009-11-27T07:07:09Z

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 P&C 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

2009-11-27T06:59:51Z

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.hanclik@...

-----Original Message-----
From: public-webapps-request@... [mailto:public-webapps-request@...] 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.

[widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December

2009-11-27T06:50:14Z

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

2009-11-27T06:44:08Z

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] Testing ITS support

2009-11-27T06:25:13Z

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 P&C test suite does not include any test cases
that overlap test cases created for ITS.

-Art Barstow

[widgets] test suite, duplicated test

2009-11-27T05:28:20Z

Hi all,

I noticed that the following two tests are the same (minimal config.xml). Maybe one of them should be removed or modified.

http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-xGYcVTMoAX/000/ds.wgt
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-MFcsScFEaC/000/d3.wgt

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: [widgets] about test d1.wgt

2009-11-27T05:02:23Z

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.concolato@...> 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

2009-11-27T04:22:15Z

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> Source Result Result Result Result

LOCALIZATION NOTE

Local - In <its:span> with mixed notes Source Result Result Result Result

TERMINOLOGY

Local - In <its:span> Source Result Result Result Result

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 <marcosc@...>

Dear i18n WG,
During the call to transition the Widgets Packaging and Configuration specification (P&C) [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] Testing ITS support

2009-11-27T03:46:23Z

Hello Marcos,

As a first step, could you take a look at our dir tests for HTML and see if
there's anything there that could be adapted? Go to
http://www.w3.org/International/tests/list-html-css#direction

Cheers,
RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

> -----Original Message-----
> From: public-i18n-core-request@... [mailto:public-i18n-core-
> request@...] On Behalf Of Marcos Caceres
> Sent: 27 November 2009 10:15
> To: public-i18n-core@...
> Cc: public-webapps
> Subject: [widgets] Testing ITS support
>
> Dear i18n WG,
> During the call to transition the Widgets Packaging and Configuration
> specification (P&C) [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: Selectors CR criteria

2009-11-27T03:45:15Z

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. $("div>p");
instead of document.querySelector("div>p");).

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [widgets] test-suite, default xml:lang

2009-11-27T02:29:08Z

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="fr">A</name>
<name xml:lang="kr">B</name>
<name xml:lang="it">C</name>
</widget>

My guess would be: ""

<widget xmlns="http://www.w3.org/ns/widgets">
<name xml:lang="fr">A</name>
<name xml:lang="kr">B</name>
<name>D</name>
<name xml:lang="it">C</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

[widgets] Testing ITS support

2009-11-27T02:14:45Z

Dear i18n WG,
During the call to transition the Widgets Packaging and Configuration
specification (P&C) [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/

Selectors CR criteria (was re: Something else)

2009-11-26T14:54:08Z

On Thu, 26 Nov 2009 23:04:35 +0100, Sean Hogan <shogun70@...>
wrote:

> Lachlan Hunt wrote:
...
>> * The implementations must be native implementations in shipping
>> products. (JavaScript library implementations don't count).
>>
> What is the reason for the native implementation requirement?
> Is it W3C policy?

Nope. But we figured that we wanted this to be clearly tested for the real
world, and some people think that insisting on it being native
implementation shows that more clearly.

cheers

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com

Re: CfC - publish Selectors API as CR

2009-11-26T14:04:35Z

Lachlan Hunt wrote:

> Maciej Stachowiak wrote:
>>> The proposed exit criteria are in a separate thread, but essentially
>>> are:
>>>
>>> For a set of tests based on HTML, CSS 2.1 selectors and this spec,
>>> there are two implementations that pass every test interoperably, and
>>> do not fail any "additional" tests based on misimplementing this
>>> specification (i.e. failures based on not supporting a technology used
>>> only in the additional tests, such as MathML, will not be taken into
>>> account).
>>
>> Request for clarification. Does this require:
>>
>> A) There must be two implementations, each of which passes every test
>> (i.e. the same two implementations pass all the tests); or
>> B) For each test, there are two implementations that pass it (but not
>> necessarily the same two for every test).
>>
>> It reads like (A), but I have seen similar wording interpreted as (B) in
>> the context of other specs...
>
> The intention in the original exit criteria proposal [1] was for there
> to be at least two complete implementations, each passing 100% of the
> baseline tests. I can make this clearer in the exit criteria as follows:
>
> ---
>
> There must be at least two complete, independent implementations, each
> of which must pass 100% of the baseline testsuite and should pass
> additional tests, dependent on the following conditions:
>
> * The implementations must be native implementations in shipping
> products. (JavaScript library implementations don't count).
>

What is the reason for the native implementation requirement?
Is it W3C policy?

Sean

Re: CfC - publish Selectors API as CR

2009-11-26T13:42:32Z

On Thu, 26 Nov 2009 21:05:31 +0100, Boris Zbarsky <bzbarsky@...> wrote:

> On 11/26/09 9:58 AM, Lachlan Hunt wrote:
>> Actually, correction. Minefield and Opera don't meet the condition if we
>> keep the shipping requirement in the exit criteria.
>
> Which imo we should. I don't think we want to be opening up that
> loophole.

I agree. Without it, we could end up in a situation where there are two
development builds passing the testsuite, so the spec exits CR, and during
the beta phase the implementors find that something needs to change for
Web compat.

I think we should maybe even require the implementations to have been
shipping for some amount of time, since some issues aren't found until the
implementation is used on a wide scale.

--
Simon Pieters
Opera Software

Re: CfC - publish Selectors API as CR

2009-11-26T13:36:13Z

Boris Zbarsky wrote:
> On 11/26/09 9:58 AM, Lachlan Hunt wrote:
>> Actually, correction. Minefield and Opera don't meet the condition if we
>> keep the shipping requirement in the exit criteria.
>
> Which imo we should. I don't think we want to be opening up that loophole.
>
> The Gecko 1.9.2 branch builds have the null/undefined issues, right?

If that's the branch that's going into Firefox 3.6, yes.

Personally, I added the shipping requirement to the exit criteria when I
revised it earlier today for basically the same reasons you outlined in
your other e-mail, so I agree we should keep the requirement.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: CfC - publish Selectors API as CR

2009-11-26T13:16:10Z

On Thu, 26 Nov 2009 21:08:31 +0100, Boris Zbarsky <bzbarsky@...> wrote:

> On 11/26/09 11:52 AM, Charles McCathieNevile wrote:
>> And I don't see any problem with using public development builds.
>
> The main problem I have with them is that they have typically not gone
> through the sort of full QA cycle that would point out possible problems
> in the implementation of the "bad interaction with other specs or
> deployed content" kind. One would hope that such issues were caught
> during spec writing, but I think this is an important sanity-check.
>
> Of course in this view not all implementations are equal (e.g. a
> walled-garden implementation wouldn't have the same compatibility
> constraints as web-facing one)... Not sure that others see this
> requirement in the same light as I do.

The CSS WG relatively recently dropped this requirement. Developer builds
are now sufficient. I was not really in favor, but most of the group was.

--
Anne van Kesteren
http://annevankesteren.nl/

Re: CfC - publish Selectors API as CR

2009-11-26T12:08:31Z

On 11/26/09 11:52 AM, Charles McCathieNevile wrote:
> And I don't see any problem with using public development builds.

The main problem I have with them is that they have typically not gone
through the sort of full QA cycle that would point out possible problems
in the implementation of the "bad interaction with other specs or
deployed content" kind. One would hope that such issues were caught
during spec writing, but I think this is an important sanity-check.

Of course in this view not all implementations are equal (e.g. a
walled-garden implementation wouldn't have the same compatibility
constraints as web-facing one)... Not sure that others see this
requirement in the same light as I do.

-Boris

Re: CfC - publish Selectors API as CR

2009-11-26T12:05:31Z

On 11/26/09 9:58 AM, Lachlan Hunt wrote:
> Actually, correction. Minefield and Opera don't meet the condition if we
> keep the shipping requirement in the exit criteria.

Which imo we should. I don't think we want to be opening up that loophole.

The Gecko 1.9.2 branch builds have the null/undefined issues, right?

-Boris

Comments on Last Call Working Draft of XHR

2009-11-26T09:25:57Z

Hopefully you'll get a formal response from the i18n WG shortly. In the meantime, I have only a couple of personal editorial suggestions:

[1] 2.2 terminology
It would help a lot to link each of the terms defined in html5 to the appropriate location in the html5 spec, if possible.

[2] same section

I was confused by the term "document's character encoding". I suspect this ought to be "character encoding (of the document)", where the parenthesised text is non-bold. The problem was that I thought "document's character encoding" was a single term, like "URL character encoding", and was something different than "character encoding" (in the same way that "document character set" is different from "character set").

Hope that helps,
RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

Re: CfC - publish Selectors API as CR

2009-11-26T09:15:27Z

> BlackBerry 9700 browser:
> (Kartikaya Gupta from RIM e-mailed me off list about this to tell me,
> I'm unable to verify these results myself without access to the
> device.)
> Baseline Tests: HTML/CSS2.1: PASS
> Additional Tests: HTML/CSS3: PASS
> Additional Tests: XHTML+SVG/CSS3: PASS

Slight correction, the 9700 publicly-available build has some of the tests failing. The BlackBerry 9550 does pass all tests though. I ran the tests on the device simulator available from http://na.blackberry.com/eng/developers/resources/simulators.jsp and grabbed the following screenshots of the completed tests:

http://stakface.com/pub/mango/selapi-suite1.jpg
http://stakface.com/pub/mango/selapi-suite2.jpg
http://stakface.com/pub/mango/selapi-suite3.jpg

Note that if you plan to try this out yourself on a device or the simulator you'll need to uncheck the "Terminate slow-running scripts" checkbox in the browser options for it to work, since otherwise our javascript watchdog will kick in and kill the script before it's done.

Cheers,
kats

Re: [widgets] about test d1.wgt

2009-11-26T08:58:01Z

Hi Marcos,

Marcos Caceres a écrit :

> Hi Cyril,
>
> On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato
> <cyril.concolato@...> 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."
>>
>
> 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>

Regards,

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: CfC - publish Selectors API as CR

2009-11-26T08:52:21Z

On Thu, 26 Nov 2009 15:58:56 +0100, Lachlan Hunt
<lachlan.hunt@...> wrote:

> Lachlan Hunt wrote:
>> There must be at least two complete, independent implementations, each
>> of which must pass 100% of the baseline testsuite and should pass
>> additional tests, dependent on the following conditions:
>> ...
>>
>> The current state of implementations is as follows:
>>
>> Minefield:
>> Baseline Tests: HTML/CSS2.1: PASS
>> Additional Tests: HTML/CSS3: PASS
>> Additional Tests: XHTML+SVG/CSS3: PASS
>>
>> Opera gogi (Internal build)
>> Baseline Tests: HTML/CSS2.1: PASS
>> Additional Tests: HTML/CSS3: FAIL 4 (non-API bugs)
>> Additional Tests: XHTML+SVG/CSS3: FAIL 22 (non-API bugs)
>> ...
>>
>> With Minefield and BlackBerry, we have two complete implementations
>> passing everything. Opera's results also meet the above criteria, so
>> that gives us 3 implementations.
>
> Actually, correction. Minefield and Opera don't meet the condition if
> we keep the shipping requirement in the exit criteria. But as soon as
> either of those builds make it into release products, we'll be good to
> go. Alternatively, we could just say public development builds are good
> enough, and Minefield would count, but I don't see any problem with just
> waiting.

And I don't see any problem with using public development builds.

Opinions?

cheers

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com