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

On 6/29/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

But they cannot be ODF interoperable if they do so.

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

Not in terms of usage/number of users.

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

That "hypocrisy" is better remedied by making other features mandatory, not by eliminating the requirement of preserving medatadata. And market forces can not produce an ecosystem of ODF documents that are portable among all ODF applications. That takes conformance requirements and validators.

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


Sure, just like they lined up to support the foreign elements and attributes.
One can only wonder why the W3C chose to include conformance requirements in RDF. Obviously, they simply did not understand that no one would possibly consider writing non-conformant RDF, even to create a competitive advantage over those who wrote conformant RDF.

I've got an idea, since the market does such a wonderful job of encouraging conformance, why don't we just do away with the conformance section of the ODF specification? Oh, I forgot, an empty Zip file is a conformant ODF document, so I guess we already did away with the conformance section.

<sarcasm />

Seriously, the issue under discussion is not the support for the xml:id attribute (except for the Sun statement that it does not intend to fully implement the metadata SC work, which cuts against your analysis), the issue is whether applications should be allowed to destroy xml:id attributes. So far, no one has offered a plausible reason why conformant applications should be allowed to destroy those attributes except by user-initiated actions. And noi one has offered a use case illustrating any need for any programmatic destruction of those attributes. Do you have one?

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