Re: [office-comment] OpenDocument-v1.2-draft6.odt / Par. 1.5 page39 preservation arbitrary element content from should to shall

[Patrick Durusau <patrick@durusau.net>]

Timo,

Openoffice Development wrote:
> To the OpenDocument technical committee
>
> Zwijndrecht, 05/11/07
>
> Subject : OpenDocument-v1.2-draft6.odt / Par. 1.5 preservation arbitrary
> element content from should to shall
>
> Dear members of the committee,
>
> First let me introduce myself. I sometimes develop software both in a
> professional environment as for leisure. I'm studying the odf tool kit
> from the OpenOffice.org community to implement it in a (internal)
> business application. To have a good implementation one should look to
> the specification and not to the produced file from an application.
> Therefore I read with great interest the document “Open Document Format
> for Office Applications (OpenDocument)v1.2 ” (document :
> OpenDocument-v1.2-draft6.odt ). And in particular chapter 1.5 (page 39)
> This chapter states that :
>
>    *
>
>      /elements contained within the /|/<office:meta>/|/ element
>      ///may/// have arbitrary element content and ///should/// be
>      preserved. See section ./
>
> A text with similar meaning can be found in version 1.0 and 1.1 of the
> specification for OpenDocument. It surprises me that this is not *shall*.
>
Appreciate any and all comments! Welcome to the ODF community!

> Arguments:
>
> In the specification room is made for “Custom Metadata” ( paragraph 3.2)
> this feature greatly simplifies processing instructions for automatic
> document processing and gives room for organisation specific meta data.
> But at this moment OpenDocument applications may throw away these
> because of the word *should.* This can cause trouble in the following
> not so hypothetical situation. Image an application which makes
> OpenDocument files with custom metadata, this metadata is used by
> another application to process the document further. But the user can
> also choose to edit this document by a third OpenDocument processing
> program which is “off the shelf”. Then when this document is stripped of
> its custom metadata by this program the reading application will run
> into serious trouble by processing this document.
>
> Technical Arguments:
>
> Why should applications throw away tags which are not recognized by the
> application, certainly when they are in enclosed in a well defined
> <office:meta> element. The “overhead” will be minimal ,namely simply
> ignore the tags which are not known.
>
> Request:
>
> Because of the ramifications of deleting custom metadata and the simple
> implementation of leaving them untouched I would like to kindly ask the
> commission to consider the proposal to change the sentence on page 39 of
> the specification:
>
>    *
>
>      /elements contained within the /|/<office:meta>/|/ element
>      ///may/// have arbitrary element content and /*//should//*/ be
>      preserved. See section ./
>
> into
>
>    *
>
>      elements contained within the |<office:meta>| element /may/ have
>      arbitrary element content and */shall/* be preserved. See section .
>
> Altough I know this specification is for preview only I would to do the
> proposal now so it can be considered for the new revision. I'm more than
> happy to give more clarification on this subject.
>
Well, and I am speaking as a standards person and not an implementer, 
there is a good reason why it is "should" and not "shall."

Consider what happens when an application opens and ODF file: It reads 
the markup and content into data structures which then present the 
content to the user for viewing/printing/modification. (Yes, I am 
limiting myself to a very common type of application for ODF, there are 
others.)

Let's assume that I modify the file, say adding a few paragraphs to the 
end and then want to save the file, that is to write back out an ODF 
format file.

If the application has "ignored" the markup as you suggest, it isn't 
anywhere to be found when the data structures internal to the 
application are written back out to ODF format.

Now, you may say that the solution is to require that all ODF 
applications store *all* the markup in an ODF file.

Not a bad suggestion but it is one that limits ODF applications to 
people who have the resources and need to write entire office suite 
software packages.

As the standard reads now, I can create a very "lite" weight ODF 
applications that only perform as much of the standard as is useful for 
some customer. And yet the resulting file will still be usable by a 
fuller ODF application. I think of that as being a feature and not a 
bug. ;-)

But, the ODF TC is not unmindful of the need to specify parameters for 
classes of applications, one of which might be, preserves all metadata 
but my understanding of the roadmap is that we are going to be taking 
that up in ODF 1.3. That is there will be "profiles" to which ODF 
applications can conform and each of those will have specified 
characteristics.

Thanks again for the comment!

Hope you are having a great day!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)