- From: Cyril Concolato <cyril.concolato@enst.fr>
- Date: Wed, 06 Jan 2010 09:56:09 +0100
- 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 UTC