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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


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


Timo,

Well, my point is that it is easier to say "preserve" all the metadata 
than it is to specify clearly what that means.

For example, the new metadata proposal not only allows for more granular 
metadata, i.e., not simply at the document level, but you can also have 
asynchronous metadata (think contract negotiations) where each party has 
their own metadata for a document.

What would it mean to say "preserve all metadata" when the metadata is 
asynchronous?

And note that metadata in ODF 1.2 is not simply the "standard" metadata 
you see in ODF 1.0/1.1 but a rather sophisticated new form of metadata 
that relies upon RDF/XML.



Looking forward to hearing more about your research in this area. Can't 
ever tell, there may be a solution lurking out on the Web somewhere.

Hope you are having a great day!

Patrick

Openoffice Development wrote:
> Zwijndrecht (The Netherlands) , 07/11/07
>
> Dear Patrick,
>
> Thank you for your kind reply of 06-11-2007 , in the light of the mail 
> of Mr. Søren Roug I think I have to clarify my mail a little bit 
> further. In my proposal I'm only speaking about elements within the 
> <office:meta> element as described in lines 114 till 130 in the 
> document OpenDocument-v1.2-draft6.odt. The data contained in this 
> element is most of times located in the file “meta.xml”. (Table 4 - 
> Root elements , page 43).
>
> File size of meta.xml discussion:
>
> This will be in most cases a small file. There are only 17 elements 
> which are defined , one element is already open for user data and the 
> specification leaves space for custom elements. One could argue that 
> an application which must preserve all the data will need considerable 
> resources because the file can grow theoretically very large. This is 
> not very probable, for example the Dublin Core standard (ISO 
> 15836:2003) has a count of 15 elements of which 6 are already included 
> into this specification. Another example is the ECMA standard 376 
> (Please don't shoot it's an example ;-)) where 43 document meta data 
> elements are defined ( Part 3, Paragraph 7.2, page 438). It is not 
> very likely that an user application will add hundreds of elements 
> extra because this will consume resources and even worse time for the 
> application in question as well.
>
> Test done:
> As an experiment I have taken the AODL project from the OpenOffice.org 
> community. The metadata is read from the “meta.xml” file into a 
> datastructure (DocumentMetadata) . The program can simple take out the 
> elements it's needs and with almost no extra effort all the data can 
> be saved into a file 
> (/adocumentreference./DocumentMetadata.Meta.Save("/filename/")) and 
> all the elements are preserved including own added elements.
>
> I fully agree with you that it would not be desirable to preserve 
> custom elements within mark-up and/or content of a document this would 
> lead to unwanted situations and require considerable resources of an 
> OpenDocument application.
>
> Conclusion:
> Changing the word *should *to *must *for conserving custom elements 
> within the <office:meta> element will not lead to “havier” 
> applications. Quick scan research even shows that even “lite” 
> application can implement this with little extra effort. This was a 
> quick scan, more research should be done to fully prove this.
>
> If there are any questions, remarks please don't hesitate to contact me.
>
> Yours truly,
>
> Timo hartong
> Zwijndrecht
> The Netherlands
>
>>
>>
>> Hope you are having a great day!
> Always...

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




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