RE: [oic] Advisories 0001 First Attempt

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Bart,

1. Regarding the serial numbering.  The location on the main trunk of the
repository (and in any label that is created as the base for an extracted
document) is a kind of unique ID.
   My concern is with the need to have a centrally-managed sequence number,
although it is not a strong concern.
   I recommend that there be a title as well as a number so we can have a
clue what one of these is about in any sort of index or guide.  
   The Scope field does not serve this purpose.  I also think the Scope
field should be a Summary or something like that.  Scope seems to be an odd
term to use based on the example.
   With regard to versioning, we have the interesting problem that the
repository itself does not apply SVN version numbers to the material.  A
working copy has them, when updated from the repository, but they are not
shown in the web view and are indeed not retained in the document on the
repository.  This peculiarity of SVN complicates our efforts to maintain
physical versioning.  I guess we have to run our own revision numbers in the
advisory documents and probably a time-stamp too.

5. The business about not preserving what you don't understand is a policy
question and I would be really surprised if any implementation does such a
thing.  Even with IS 29500-3 MCE (as I recall, so this is not a trustworthy
statement), the indication to preserve something that is not understood is
advisory (e.g., reliance on external knowledge to indicate that preservation
is safe) but can be trumped by other considerations including difficulty of
holding onto such material in the internal model so that it is dropped
properly if the containing element, understood contained material, or
alternatively-understood element are edited.

In the experiment I did with test-0002 and test-0003, it appears that
Microsoft Office Word 2007 does not preserve unsupported elements/features
between consumption and production of a different ODF Text document.  I
cannot speak for them as far as the policy issues go, of course.  Just
observing something at least one implementation is doing within the umbrella
of conforming behavior.

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Friday, June 11, 2010 04:57
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Subject: RE: [oic] Advisories 0001 First Attempt

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


[ ... ]

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