W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

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

From: Cyril Concolato <cyril.concolato@enst.fr>
Date: Wed, 06 Jan 2010 09:56:09 +0100
Message-ID: <4B445029.30408@enst.fr>
To: Marcos Caceres <marcosc@opera.com>
CC: public-webapps <public-webapps@w3.org>
Le 05/01/2010 23:29, Marcos Caceres a écrit :
> On Wed, Dec 9, 2009 at 1:50 PM, Cyril Concolato<cyril.concolato@enst.fr>  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")
Fine.

>
>> 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.
I agree.

>
>> - Change the similar point for the icon element.
>
> As above.
I agree.

>
>> - 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.
You're right it's a bit long but I'm also fine with it.


>
>
>> 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...
I was not saying that I don't like the separation between steps and rules. It's just the structure of Section 9 that I find weird. It's ok if you don't change the spec now. you can keep it in mind for a 2nd edition or a 1.1 version :)

> 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.
I agree, this proves that the spec and the test suite are both in good shapes.

FYI, out of the 166 tests, GPAC fails 7 because of XML/Unicode handling. This will probably be fixed. 1 fails because we don't implement SNIFF. I don't know if we will. 3 fail because we don't maintain tables of supported mime types, encodings or features, at the level of the widget UA. I don't know yet how to fix that. The last failure is related to the handling of invalid feature elements, on which I disagree with the test suite (see next email). So hopefully, I should get close to the 100% in the future.

Cyril
-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/widgets/
Received on Wednesday, 6 January 2010 08:56:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT