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 Metadata proposal


Thomas,

On 6/30/07, Thomas Zander <zander@kde.org> 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.

I'm not referring to that. I'm referring to preservation of attributes
and files, irrespective of support for specific features.

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

Absolutely agreed. This is not in any way specific to metadata. So
let's make sure to keep these issues separate.

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

As I said: I'm not in any way saying it should be mandatory ODF 1.2
applications support metadata. That's a red herring, so can we please
put that aside?

I'm saying it should be mandatory that applications don't destroy
crucial data!

The crucial bit here is: what is it OK for an application to do with
optional (or foreign) attributes? The new xml:id attribute we rely on
for metadata is just one example of this, but I'm sure there are
others. Is it OK for an application to read that data in but throw it
out?

Or files it doesn't know about: is it OK for an ODF application to dump them?

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

Thanks :-)

But as I say above, there is a larger question here about preservation
of files and attributes.

Bruce


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