Re: One <feature>, multiple resources

After looking at the spec a bit more closely, I noticed that the
following requirement from how to process a feature element (Step 7):

"If the name attribute of this feature element is absent, then the
user agent must ignore this element."

I've now added that.

We had tests for this behavior in the test suite:

http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-rZdcMBExBX/000/
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-rZdcMBExBX/001/

But it was not explicitly written into the spec :(

Kind regards,
Marcos

On Tue, Feb 2, 2010 at 4:27 PM, Marcos Caceres <marcosc@opera.com> wrote:
> (IMPORTANT: New test in the test suite, please see below if you have
> already submitted your results)
>
> On Fri, Jan 29, 2010 at 1:45 PM, Arve Bersvendsen <arveb@opera.com> wrote:
>> This is an excerpt of something I wrote on the #webapps IRC channel:
>>
>> <arve> hm
>> <arve> I have some exploratory work here (not going into details)
>> <arve> let's just say that <param > for feature isn't enough
>> <arve> but an example is actually Opera's own Unite
>> <arve> (looking a bit further, though)
>> <arve> let's say I wanted to spawn two workers, each with their own web
>> service
>> <arve> simply speaking, I can't
>> <arve> currently, all I can do is:
>> <arve> <feature name="http://xmlns.opera.com/webserver">
>> <arve>     <param name="type" value="service" />
>> <arve>     <param name="servicepath" value="foo" />
>> <arve>   </feature>
>>
>> The problem is roughly that the param key-value pair is insufficient when a
>> <feature> needs to both specify and configure multiple resources, such as
>> one Opera Unite widget configuring two different web services. The example
>> above could only ever load one single service per widget (and it would be
>> what's specified in the widget's <content> element, to boot). A widget which
>> wanted to configure one document per widget would need to nest the <param>'s
>> in something.
>>
>
> The spec purposely does not give guidance on what to do when two
> features with the same name are encountered, apart from parsing them
> as normal. Hence, given the following, the feature list would end up
> with two objects containing distinct parameters.
>
>  <feature name="http://xmlns.opera.com/webserver">
>    <param name="type" value="service" />
>   <param name="servicepath" value="foo" />
> </feature>
>
>  <feature name="http://xmlns.opera.com/webserver">
>    <param name="type" value="service" />
>   <param name="servicepath" value="bar" />
> </feature>
>
> It would then be left up to the implementation to make use of those
> objects as it sees fit, or, the specification that defines the said
> feature, needs to give guidance as what to do in case of a name
> collision.
>
> I've added the following test to the test suite:
>
> <test id="ha" for="ta-rZdcMBExBX" src="test-cases/ta-rZdcMBExBX/002/ha.wgt">
> Test the UA's ability to handle multiple feature elements with the
> same value for the name attribute, but with different param elements.
> To pass, the feature list must contain two features. Both are named
> 'feature:a9bb79c1'. One feature must have a parameter named "test"
> whose value is "pass1"
> The other feature must have a parameter named "test" whose value is
> "pass2" (the order in which the features appear in the feature list in
> not relevant).
> </test>
>
>
>
> --
> Marcos Caceres
> http://datadriven.com.au
>



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

Received on Tuesday, 2 February 2010 16:08:05 UTC