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 ofadvisories


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.

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

Hi Dennis,


> I think there are two separate issues.

Indeed

> One is not about hiding tracked changes so much as extracting in-line text
> (which will exclude tracked changes).  It looks like the problem first
seen
> is related to doing that incorrectly (and a bug in the list of exceptions
to
> in-line text).

That would be the OFFICE-2706, correct ?

>This applies to many other situations.

Mm, like annotations ? Or other implementations (eg: search engines indexing
"removed" text)


> Another is about what to do when tracked-changes are not supported and
> whether producers that do not support tracked changes should preserve the
>text:tracked-changes element and the markers that show up in the character
> data of the in-line text.
>
> It would be valuable to deal with these as a pair, not as one.

So should we create a separate Advisory for that ? Or just deal with it in
the
same Advisory, but make a clear distinction between them ?


> I haven't looked closer, but the name change seems to invite treating them
> together.

Actually I was focusing on the first one ("if you don't support changes, do
not
render the contents of the text:p and text:h's inside text:tracked-changes
as if
it was part of the document flow")


Best regards,

Bart

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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