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-metadata] Re: [office] Re: [office-metadata] Suggested Changes on the Metadata proposal




On 6/30/07, Patrick Durusau <patrick@durusau.net> wrote:
Thomas,

I am curious about the term "support" in this context.

Does preservation of data imply that a feature is supported?


FWIW, the RFC 2119 definition of "may" that applied to ODF 1.0  draws a distinction between implementation and interoperability, the latter of which can obviously require  preservation of data:

"5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) "

<http://www.ietf.org/rfc/rfc2119.txt>

In other words, what if I have a very lite weight application that
doesn't actually read any of the content of an ODF file or parse any of
the existing metadata files but simply adds an entry to the metadata
manifest to add metadata about the document as a whole (such as would
happen in a clerk of court's office with filing date, who filed it,
etc.) and added an appropriate metadata file. It then saves *all* of the
file.

Granted, I haven't implemented a lot of the features offered by ODF but
I have preserved the file, even for features I don't support.

Is there a useful distinction to make between implementation of a
feature and preservation of a file's contents that you are given for
processing?

There certainly is at least for the Foundation's MS Office ODF plug-in. It implements no ODF features whatsoever, merely converts between one format and another. And to do so, preservation of metadata that can not be mapped is essential to its round-tripping of documents.
 
Likewise, I know of only two methods for allowing the less featureful ODF apps to round-trip documents with the more featureful ODF apps. One is to declare interoperability subsets and create corresponding compatibility modes in the apps at both ends of the round-trip. The other is to require the preservation of unsupported metadata.

Granting that I could also implement a very lite weight application that
doesn't offer metadata or any number of other features since we don't
require an application to implement any specific set of features.

So, is preservation separate from feature implementation? (I am asking
because I haven't seen it raised in this context and while it seems
evident to me the two are different, opinions may and probably do vary
on that point.)

Hope you are having a great day!

Patrick

Thomas Zander wrote:
> On Friday 29 June 2007 17:30:38 Bruce D'Arcus wrote:
>
>>> Therefore it seems best to keep these rules optional unless the
>>> application plan to implement the metadata feature.
>>> And when I mentioned ODF applications, I do not meant OpenOffice.org,
>>> for which it won't be a problem as we desire the feature.
>>>
>> I strongly disagree. Preserving files and attributes is a trivial
>> requirement. Not doing so will introduce large compatibility problems.
>>
>
> This, naturally, is not an isolated case. There currently are no
> applications that support all the ODF features but they still can be ODF
> compliant.  Even should one loose 90% of the features between loading and
> saving.
>
> So the question becomes, is metadata any different. I'm inclined to say
> no.  Its not different, its just a feature that the application should
> support. If it doesn't then a better application comes along and replaces
> it.
> Looking at the ODF landscape I consider this;
> * OOo and KOffice both think its a good feature to support, and are both
> moving to do so.  I'm sure other big office suites agree and do so as
> well.  Meaning that ODF doesn't have to force their hands.
> * Almost all professional users of office suites benefit from metadata in
> one way or another. So an application that follows user requests will
> quickly see metadata on their TODO list.
> * There are not that many application-types that both load and save ODF
> files. Viewers and writers are the bigger segment. We are only concerned
> with the load+save type.
>
> Bottom line is that while I fully agree its very important to retain this
> information that does not automatically imply that ODF has to make it
> mandatory. Market forces can do that too.
> Furthermore I would find it hypocritical to make it mandatory while almost
> all features in ODF are not mandatory to be retained between load and
> saves.
>
>
>> Really, just to be clear: if applications do not preserve xml:id
>> attributes, fields will break, and any metadata about document
>> fragments will be made invalid. Is that really in anyone's interest?
>> They need not support metadata in any explicit way to do this.
>>
>
> I think this said is best; things will break in a very visible way if apps
> don't support it.  So users will quickly realize a problem and apps will
> be requested to support the feature of metadata.
>
> The only reason I see to make it mandatory is for fear of people not
> supporting it, and I can easy your mind there, you guys have been doing
> an awesome job. Applications will line up to support this stuff. Don't
> worry so much! :)
>
>
> ps. not sure if I have write access to the metadata ML, if this doesn't
> appear there, please consider forwarding. Thanks.
>

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