Re: [widgets] feature: inconsistent behavior ?

[Marcos Caceres]

On Wed, Dec 16, 2009 at 10:13 AM, Cyril Concolato
 wrote:
> Hi,
>
> The test df.wgt contains a feature without name. In this case, the feature
> element is ignored and the widget remains valid.
> The test d4.wgt contains an invalid feature name. In this case, the widget
> should be considered as invalid. I don't understand that. I understand the
> rationale that if a feature is required, the UA shall not process the
> widget. Whether it does or not understand the feature, it doesn't matter. Is
> it because you foresee evolution in the syntax of feature names, which
> wouldn't be IRI ? If not, I suggest to make this test pass and ignore the
> feature element.
>

Sorry, but it was a resolution that all correctly named features are
considered required (it's why we had to create the required
attribute). I'm against changing this.



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

[UMP] updated editor's draft of "Uniform Messaging Policy" on W3C site

[Tyler Close]

I've uploaded an updated version of "Uniform Messaging Policy, Level
One" to the W3C web site. See:

http://dev.w3.org/2006/waf/UMP/

This version reflects feedback received to date and follows the
document conventions of a FPWD.

I look forward to any additional feedback.

Thanks,
--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Re: [widgets] P&C simplifying some rules (editorial)

[Marcos Caceres]

On Wed, Dec 9, 2009 at 1:50 PM, Cyril Concolato  wrote:
> Hi all,
>
> I noticed that "9.1.3. Rule for Finding a File Within a Widget Package"
> indicates that the "algorithm returns either a file, null, or an error.".
> This is not exactly true since if it does return an error or null, it always
> returns a "processable file".

Ok, clarified this in the spec (that is, returns a "processable file"
instead of just a "file")

> I suggest changing the introduction as follows "The algorithm returns either
> a processable file, null, or an error." and then doing the following three
> edits:
>
> - Change point 7 in the license element in "9.1.15. Algorithm to Process a
> Configuration Document" to indicate:
> "If file is null or there is an error in 6 then ignore this element"

I don't agree with this change. The point already says:

"If file is not a processable file"

This implicitly means "if file is null or in error" or anything else.

> - Change the similar point for the icon element.

As above.

> - Simplify "Step 9 - Process the Default Icons" by collapsing A.A, A.B and
> A.C into
> "if potential icon is null or in error or already exists, ignore it"

The above is not precise enough for my liking, but it made sense to
collapse it a given that a processable file is always returned... so,
I've changed it to:

"If the potential-icon is a processable file, determined by the media
type given in the media type column of the default icons table, and
the potential-icon does not already exist in the icons list of the
table of configuration defaults, then append the value of
potential-icon to the icons list of the table of configuration
defaults."

It's a somewhat long sentence, but I can live with it... and it
doesn't change what was already there.


> Also, I was wondering for quite some time why the spec has a strange
> structure for Rules vs. Steps. Couldn't you put all the Rules into one
> section 9.1 and all the Steps in 9.2?

Yeah, admittedly, it got a little messy wrt what defines a rule and
what defines a step... that was me doing crazy literary experiments in
the hope of making the spec easier to read and work with... I wanted
to write rules like they were reusable functions, and the Steps as if
they were independent parts of a program... not sure if I succeeded,
but generally I get people saying they like the way I structured the
spec... but have also been told it's confusing. So, you are probably
correct that what is defined in Step 9 should have been a rule (and
hence gone into 9.1). I don't think there is much point now in
changing it, however. We should just be trying to squish any
outstanding spec bugs (if any) and otherwise let it be... we still
have a ton of work to do on updates and view modes, so I just want to
call P&C done and start oiling the gears to move it to Proposed Rec by
the end of the month. Once GPAC and Widgeon are at 100%, we will have
5 conforming implementations which I think it's a pretty awesome
achievement and a testament to the implement-ability of the spec.

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

Re: [widgets] features: default value for required

[Marcos Caceres]

On Wed, Dec 16, 2009 at 9:50 AM, Cyril Concolato
 wrote:
> Hi all,
>
> The algorithm for processing the 'required' attribute is unclear. It says:
> "If a required attribute is used, then 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, then let the
> value of required-feature be the value 'true'."
>
> I think it misses the case when the required attribute is not used.
> According to the 'Authoring Guideline', it should say:
> "If a required attribute is used, then let required-feature be the result of
> applying the rule for getting a single attribute value to the required
> attribute. *If the required attribute is not used or *if required-feature is
> not a valid boolean value, then let the value of required-feature be the
> value 'true'."
>

I've added the above clarification to the spec. that is, the text "If
the required attribute is not used or"

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

Re: [widgets] duplicated feature elements ?

[Marcos Caceres]

On Tue, Jan 5, 2010 at 8:50 PM, Marcos Caceres  wrote:
> On Wed, Dec 16, 2009 at 10:51 AM, Cyril Concolato
>  wrote:
>> Hi all,
>>
>> There is a test in the test suite for duplicated param element with the same
>> name but different value (v9.wgt). But I did not find, a similar test for
>> duplicated feature elements with the same name. Is this allowed or not ? The
>> algorithm in Step 7 does not say.
>>
>
> This is allowed. I've added the following note to make that clear (not
> checked into cvs yet):
>
> "Note: This specification allows feature elements with the same name
> and/or value to be declared more than once. Handling of duplicate
> feature requests is left up to the implementation."
>

I made a mistake above, it should have read:

"This specification allows feature elements with the same name
attribute value to be declared more than once. Handling of duplicate
feature requests is left up to the implementation."

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

Re: [widgets] duplicated feature elements ?

[Marcos Caceres]

On Wed, Dec 16, 2009 at 10:51 AM, Cyril Concolato
 wrote:
> Hi all,
>
> There is a test in the test suite for duplicated param element with the same
> name but different value (v9.wgt). But I did not find, a similar test for
> duplicated feature elements with the same name. Is this allowed or not ? The
> algorithm in Step 7 does not say.
>

This is allowed. I've added the following note to make that clear (not
checked into cvs yet):

"Note: This specification allows feature elements with the same name
and/or value to be declared more than once. Handling of duplicate
feature requests is left up to the implementation."

I don't think it's necessary to test this; but if other people want a
test for it, I can add it.



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

Transition

[Nikunj Mehta]

Hi folks,

I am leaving Oracle today and with that I will be handing over the 
Oracle baton for this WG to Garret Swart copied on this mail.


Garret has been a key contributor internally at Oracle to both the specs 
I have been editing - Indexed Database API and Programmable HTTP Caching 
and Serving.
I am sure he will be a great help in further advancing the two specs. 
He will be joining the WG shortly as Oracle's rep.


I had an awesome experience and better appreciation for the work that is 
involved in developing standards for the Web as part of this WG. I will 
continue to blog on these topics and continue to follow their progress.


It was really wonderful to know all the people in this WG both over 
email and in face to face meetings. I wish the best to the WG in its 
mission.


Nikunj Mehta
http://blog.o-micron.com

Re: XHR LC comment: header encoding

[Boris Zbarsky]

On 1/5/10 5:03 AM, Anne van Kesteren wrote:

More concretely, this means that combined with the rules coming from
HTTP a SYNTAX_ERR exception would be raised for the value argument if
one of the characters has a code point larger than U+00FF, if the code
point is U+007F, or if the code point is smaller than U+0020 but is not
U+0009. If this is all ok the lower bytes are collected as the new
header value.

Does this sound acceptable to implementors?


Apart from the obvious worry of switching away from a behavior that the 
vast majority of UAs currently implement, with the ensuing potential for 
website breakage, sounds fine...


-Boris

[widgets] Reminder: RfC for LCWD of Widget Access Request Policy spec; deadline 13-Jan-2010

[Arthur Barstow]

Reminder: January 13 is the deadline for comments for the 8-Dec-2009  
Last Call Working Draft of the Widget Access Request Policy spec:


 http://www.w3.org/TR/2009/WD-widgets-access-20091208/

If you have any comments, please send them to:

 public-webapps@w3.org

-Art Barstow

Begin forwarded message:


From: "Barstow Art (Nokia-CIC/Boston)" 
Date: December 8, 2009 2:06:55 PM EST
To: public-webapps 
Subject: [widgets] Request for Comments: LCWD of Widget Access  
Request Policy spec; deadline 13-Jan-2010
Archived-At: 


On December 8, Last Call Working Draft (#2) of the Widget Access
Request Policy spec was published:

  http://www.w3.org/TR/2009/WD-widgets-access-20091208/

Please send comments to public-webapps@w3.org by 13 January 2010.

Robin, Frederick - if appropriate, please forward this RfC to DAP WG.

-Art Barstow

Re: XHR LC comment: header encoding

[Julian Reschke]

Anne van Kesteren wrote:

On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking  wrote:

Wouldn't it then be better to throw for any non ASCII characters? That
way we don't restrict ourself for when (if?) IETF defines an encoding
for http headers.


The defined encoding is ISO-8859-1 (unfortunately).


Well, that's debatable, as RFC 2616 wasn't sufficiently precise.

What's a fact is that some HTTP APIs treat them as ISO-8859-1 (servlet 
API, for instance).


HTTPbis currently has:

"Historically, HTTP has allowed field content with text in the 
ISO-8859-1 [ISO-8859-1] character encoding and supported other character 
sets only through use of [RFC2047] encoding. In practice, most HTTP 
header field values use only a subset of the US-ASCII character encoding 
[USASCII]. Newly defined header fields SHOULD limit their field values 
to US-ASCII characters. Recipients SHOULD treat other (obs-text) octets 
in field content as opaque data." -- 




At the very least, throwing if the upper byte is non-zero seems like
the right thing to do to prevent silent data loss.


That works for me.


Sounds good to me as well.

Best regards, Julian

Re: XHR LC comment: header encoding

[Anne van Kesteren]

On Tue, 05 Jan 2010 08:39:26 +0100, Anne van Kesteren   
wrote:
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking   
wrote:

At the very least, throwing if the upper byte is non-zero seems like
the right thing to do to prevent silent data loss.


That works for me.


More concretely, this means that combined with the rules coming from HTTP  
a SYNTAX_ERR exception would be raised for the value argument if one of  
the characters has a code point larger than U+00FF, if the code point is  
U+007F, or if the code point is smaller than U+0020 but is not U+0009. If  
this is all ok the lower bytes are collected as the new header value.


Does this sound acceptable to implementors?


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