Re: [widgets] Draft Minutes from 14 May 2009 Voice Conference

On Tue, May 19, 2009 at 1:26 PM, Marcos Caceres <marcosc@opera.com> wrote:
>
>
> On 5/19/09 12:44 PM, Arthur Barstow wrote:
>>
>> Marcos,
>>
>> On May 19, 2009, at 4:15 AM, ext Marcos Caceres wrote:
>>>
>>> On 5/18/09 7:05 PM, Arthur Barstow wrote:
>>>>
>>>> What is the status of the P&C's L10N model?
>>>>
>>>> It appears you've made some progress since the May 14 call:
>>>>
>>>> <http://dev.w3.org/2006/waf/widgets/>
>>>>
>>>> Are you blocked on anyone else's inputs/actions?
>>>>
>>>
>>> I'm not blocked by anyone, though access still needs work. Robin and I
>>> are on it though. Arve also discovered some issue with <feature>, which
>>> I am addressing.
>>
>> Please elaborate on the "issue with <feature>".
>
> The issue with feature is that it is unclear as to how URIs are interpreted.
> The Generic URI spec says that the following are all the same:
>
>      http://example.com
>      http://example.com/
>      http://example.com:/
>      http://example.com:80/
>
> The XML namespace spec, on the other hand, says that the above are all
> different!
>
> So, I had spec'ed that URIs in feature to be interpreted as Generic URIs.
> So, if I say the following:
>
> <feature name="http://example.com:/"/>
>
> and then in the start file I ask:
>
> widget.hasFeature("http://example.com") would return TRUE.
>
> Arve said that, "no, URIs should be treated as namespace URIs". In which
> case:
>
> widget.hasFeature("http://example.com") would return FALSE.
>
> The only way to get back true, would be to ask:
>
> widget.hasFeature("http://example.com:/")
>
> And, therein lies the problem :) My position was that URIs should be treated
> as Generic URIs. However, Arve pointed out, and TLR agreed, that treating
> URIs as Namespace URIs makes processing simpler (they work just like
> namespaces).
>

Ok, here is feature treated as an opaque string:
[[
If the element being parsed is a feature element:

If a required attribute is used, but no name attribute is used, then
this element, its attributes, and its children are in error and must
be ignored by the user agent.

If the name attribute is not a valid URI, then the user agent must
ignore this element, its attributes, and its children.

If the name attribute is a valid URI, then let feature name be the
result of applying the rule for getting a single attribute value to
the required attribute. If feature name is not supported by the user
agent, then this element and its children are in error and must be
ignored.

If a required attribute is used, let required feature be the result of
applying the rule for getting a single attribute value to the required
attribute. If required feature is not a valid boolean value , let the
value of required feature be 'true'.

If the feature element contains param elements as child nodes, then
for each child param element that is a direct descendant of this
feature element, starting from the first moving to the last in
document order:

If a value attribute is used, but the name attribute is absent, then
this element is in error and the user agent must ignore it.

If a name attribute is used, but the value attribute is absent, then
this element is in error and the user agent must ignore it.

For the name attribute, let param name be the result of applying the
rule for getting a single attribute value to the name attribute. If
the param name is an empty string, then this element is in error and
the user agent must ignore it.

If, and only if, param name is not in error or an empty string, let
param value be the result of applying the rule for getting a single
attribute value to the name attribute. If the param value is an empty
string, then this element is in error and the user agent must ignore
it.

Associate param name and param value with feature name.

Append feature name and associated parameters (if any) to feature list.
]]





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

Received on Wednesday, 20 May 2009 12:22:55 UTC