RE: mobileOK basic issues

Hi,

I need to side track this worthy topic a wee bit.

In working with mobileOK Pro we have discovered a few BPs that either
seem rather pointless or cannot be tested or need to be modified or
simply are some decent adivce.
I am not thinking of anything particular at the moment.  Comments to
this effect have been available in the mobileOK Pro document.


However, might it not make sense, if there is a chance to revisit BP 1.0
to deal with those issues as well?
Of course only if we decide to touch the document at all.

Kai




 

> -----Original Message-----
> From: public-bpwg-request@w3.org 
> [mailto:public-bpwg-request@w3.org] On Behalf Of Sean Owen
> Sent: Tuesday, April 15, 2008 11:47 PM
> To: Dominique Hazael-Massieux
> Cc: public-bpwg
> Subject: Re: mobileOK basic issues
> 
> 
> Muchos kudos to Dom for organizing these threads that do need 
> to get tied up so we can finally finish mobileOK Basic. I 
> would also like to agree on these on Thursday.
> 
> 
> On Mon, Apr 14, 2008 at 11:15 AM, Dominique Hazael-Massieux 
> <dom@w3.org> wrote:
> >  ISSUE-230: OBJECTS_AND_SCRIPTS needs to address &lt;object&gt; with
> >         There are 3 options on the table:
> >         1. Ignore the bug in our current algorithm as it 
> affects only a
> >         limited number of real documents (and leave it for the next
> >         version mobileOK basic)
> >         2. Use the new proposed algorithm
> >         3. remove object parsing from mobileOK basis on the 
> basis that
> >         it is too complex
> >
> >         My feeling is that proposal #2 is probably the best road.
> >  http://www.w3.org/2005/MWI/BPWG/Group/track/issues/230
> 
> Agree with Dom.
> 
> 
> >  ISSUE-231: MINIMIZE should take into account whitespace in CSS
> >         1. we include CSS white space in the test
> >         2. we leave that for a next version of mobileOK basic
> >
> >         Given that mobileOK basic 1.0 isn't specifically 
> broken with the
> >         current test, and to avoid having too many 
> substantive changes
> >         in the document, I would suggest we go with option #2.
> >  http://www.w3.org/2005/MWI/BPWG/Group/track/issues/231
> 
> Agree, while this is easier to adjust than the last issue, 
> and has a bigger impact, it also does not represent something 
> that is broken. On that basis I also strongly favor not 
> continuing the change the spec.
> 
> 
> >  ISSUE-234: Should Objects Tasted count towards the overall 
> page weight
> >         Again, two options:
> >         1. we add that algorithm in our calculation of 
> PAGE_SIZE_LIMIT
> >         2. we keep it for the next version of mobileOK basic (in the
> >         basis that the test is not broken)
> >
> >         It's not clear that there is any consensus on the topic - I
> >         would personally opt for option #2 again because 
> that's what has
> >         been picked for the two previous ones. (more 
> seriously, because
> >         I think mobileOK basic needs more to be finished 
> than perfect)
> >  http://www.w3.org/2005/MWI/BPWG/Group/track/issues/234
> 
> Agree for the same reason.
> 
> 
> >  ISSUE-240:
> >         Two proposals have been made (see a pattern here?):
> >         1. We remove the test for validity to the declared 
> DTD (on the
> >         basis that it doesn't add anything directly 
> relevant to the goal
> >         of mobileOK basic)
> >         2. We replace it to have it effective only when the 
> declared DTD
> >         matches a well-known DTD (with an explicit list of DTDs)
> >
> >         There seems to be a mild preference for #2; for sake of not
> >         having to dwelve in the details of SYSTEM ID, PUBLIC ID,
> >         equivalent URIs of well-known DTDs, I would 
> personally suggest
> >         #1 (shocking!).
> >  http://www.w3.org/2005/MWI/BPWG/Group/track/issues/240
> 
> Agree. While I am a real stickler about pushing validity, I 
> agree, this actually doesn't add much value beyond requiring 
> valid XHTML.
> Noting that you sent in a valid -- or invalid -- FOAF file 
> just doesn't matter.
> 
>

Received on Wednesday, 16 April 2008 08:35:04 UTC