RE: [oic] Advisories 0001 First Attempt

[Hanssens Bart <Bart.Hanssens@fedict.be>]

Hello Dennis,


> 1. I'm not sure that the serial numbering of these is helpful.  It will depend on how successful the
> title is in communicating what it is about.

Hmm, IMHO at least an unique ID is needed (serial or other), should make it easier to link / reuse


> 2. I suggest references to the relevant parts of ODF versions should be higher up in the advisory.

OK

> We are back to the question about status of these and whether we have to create OASIS
> documents based on their content at some point, so we will need to look at that and how we do it
> responsibly.

I suggest to have 4 states: draft / approved / replaced / revoked.

Draft: just work in progress
Approved: approved by eballot / conf call vote
Replaced: another (approved) advisory supersedes this one
Revoked: the advisory was just plain wrong

So I'd better add an optional section 'Replaces' in the HTML.

Every X months, we could grab the full text of the approved / replaced advisories + list of the revoked
advisories + whatever extra material (test files, screen shots, whatever) and create a CD out of it
(or a Note if OASIS decides that's allowed) with a section "there are no conformance clauses", store
it in Kavi, vote upon it (could be very short, since they have already been voted upon earlier)



> 4. With regard to the specific advisory trial, I suggest that the bug is assuming that anything in
> <p> or <h> elements is text of the document.  There is a section in the ODF specification that says
> this assumption is permissible and that fails to list the <text:tracked-changes> element as an
> exception.

Ow, I should add a reference to that section. Thanks.


> 5. Also, I think <text:tracked-changes> should never be preserved if not supported and the markers
> in the main text should not be preserved either.  A consumer that does not support change tracking
> and acceptance/rejection of changes needs to treat the document as if all changes have been
> accepted and the history erased.  Likewise, producers that do not support tracked changes should
> not produce any of the elements that are related to it.

Any thoughts from implementers ?


> 8. I didn't update the HTML file to reflect these additional test files.  But they are in the Advisories/00001/
> folder of the repository.

Mm, perhaps they should be stored elsewhere (or in a 'result' folder), as they are the result of loading
the test file (for round-tripping, one might want to look at officeshots.org by the way)

 
Best regards

Bart