OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [oic] Version Control Commit by bart.hanssens - file names of advisories


That separation into two advisories would work.  I favor it.

 - Dennis


If you are concerned about scope creep in advisory 0001, you could still
limit it to incorrectly displaying removed text that is set aside in tracked
changes.  I don't think we need to do that though.
 
I don't know think there needs to be test cases for every conceivable case.
(We could probably illustrate all of the cases in a single text document
though.)

In-line text in spreadsheets and presentations are a little trickier.  I
wouldn't address those in this advisory.  Also extraction of in-line text
from [changed] table cells is also a difficult case if tables aren't
supported or the tool is performing the extraction for search indexing or
something.  Since text can be introduced arbitrarily using draw frames, and
those can appear in irregular table cells (big ones that cover a rectangle
of smaller ones) there are other cases that aren't clear-cut. (I wonder if
that is why the concept of in-line text is removed from 1.2?)

So, "incorrectly displaying non-inline text inline" probably captures the
sense of the advisory and we have tracked-changes as the poster child for
it.

What is great about doing this as an advisory is we can gather cases and
advice/experiences from others, and even incorporate more tests that reflect
discovered cases in the wild without having it all perfect right now.  And
we can use the Wiki and such to point people to advisories of any status.
Maybe the initial status is working-draft or provisional or something.

This discussion has me be satisfied that "advisory" is a good term for
these.  They are just that and they can be refined over time, even withdrawn
if that ends up being the appropriate action.  (I note that the security
advisories that reach my inbox often go through such refinement and are
occasionally updated/replaced.)

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Wednesday, June 16, 2010 23:53
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Subject: RE: [oic] Version Control Commit by bart.hanssens - file names of
advisories

Dennis,


Let's see if I get this right.


So advisory 00001 would be  "incorrectly displaying of non-inline text"

- Point to issue 2706 with spec itself
- observation that this is sometimes displayed incorrectly

I'm not sure if the advisory should say something about displaying in-line
content in
general, or focus on change tracking specifically. (Displaying of the change
tracking
elements is "clearly" a implementation bug, but technically correct per
spec).

Either one is just fine with me. But if it's a more general advisory we
should probably
create a small test docs for, say, spreadsheet with an annotation.



And advisory 00002 would be "removal of unsupported change tracking
elements"

- point to change marks and change tracking section
- recommend that implementations not supporting change tracking do remove
the
<text:track-changes>, change marks (in general, behave as if all changes are
accepted)


Best regards

Bart

________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Wednesday, June 16, 2010 8:20 PM
To: Hanssens Bart; oic@lists.oasis-open.org
Subject: RE: [oic] Version Control Commit by bart.hanssens - file names of
advisories

I think the one around consumers/producers who don't support change tracking
should be separate.

[ ... ] 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]