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

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")

> 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

Received on Tuesday, 5 January 2010 22:30:02 UTC