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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Re: [office-metadata] Suggested Changes on the Metadataproposal

I suppose I should throw in my $.02.

First, we should remember that ODF mandates behavior at several levels.  The schema itself encodes requirements in terms of what elements or attributes are optional or mandatory, what nesting is permitted, what restrictions there are on data types, etc.   And then the normative text of the standard, along with external normative references, make additional provisions by the use of "shall" and "shall not".  But note that in that case,the provision is only applicable to those who implement that feature.  A "shall" concerning the calculation of the SUM() spreadsheet function may be totally ignored by someone who is implementing a word processor only.  Finally, we have the conformance clause, that defines which features and additional constraints are required for conformance with the standard.

Today our conformance clause designates requirements for conformant documents, conformant applications that read, conformant applications that write, and conformant applications that both read and write.  

As you may already know, OASIS has added a new requirement for all OASIS standards:

"A specification that is approved by the TC at the Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof) "

When we make the changes required for the new OASIS rules, I suggest we think about conformance in general, and consider making a more substantial statement. For example, we could define things at a more granular level:  a conformant ODF spreadsheet shall support workbooks of at least a single sheet, with at least 100 rows and 25 columns and at least the Group 1 spreadsheet functions.  (Just an example, not a real proposal).  So we have the opportunity to specify multiple levels of conformance, either in the main text, or as separate profiles.

To the specific question at hand, I am concerned with the loose use of the word "preserve."  What exactly does that mean?  For example, must the xml:id's of the saved document be lexically identical to the read document?  Or are looser version of equivalence allowed?  For example, if the id originally is "foo" and then it is saved with the id "bar" is that permitted, provided that the structure and referential integrity of the id and references are maintained?   Remember, it will be common for an application to read an XML document and convert id's and links into internal runtime representations that are not at all similar to the XML.   Id/references might be converted into C-language pointer references between objects, etc.  Then when writing out the document, new unique ID's might be generated on-the-fly, perhaps in sequential order.  This might vary from implementation to implementation.  Beyond referential integrity, I don't know if there is any additional value in saying that a document created in KOffice must have identical ID labels when that document is later saved in OpenOffice.  

We should also note that it is a feature of some programs, such as Office 2007, to have a menu item specifically for removing metadata from a document, for privacy and security reasons.  I don't think we want to prevent such an application from claiming conformance.

So we need to be need to be very careful how we word this.  Perhaps something like "Conforming applications that read and write documents shall be capable of "preserving" xml:id's, etc."  With the proviso that "preserving" needs a better definition, this ensures that conforming applications support preservation, while also allowing that not every mode of use may actually do so, such as when a user deletes content or metadata, etc.


Rob Weir
Software Architect
Workplace, Portal and Collaboration Software
IBM Software Group

email: robert_weir@us.ibm.com
phone: 1-978-399-7122
blog: http://www.robweir.com/blog/

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