[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [oic] Advisories 0001 First Attempt
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]