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 Saturday 30 June 2007 20:05:04 Patrick Durusau wrote:
> Thomas,
>
> I am curious about the term "support" in this context.
>
> Does preservation of data imply that a feature is supported?

In my mails I used the term "support" as a catch all; to not complicate 
matters by being too precise that it hurst readability.
In reality; to support a feature the work that an implementation has to do 
differs per feature.
A feature might be numbered lists. And that means that the application has 
to parse the list and the numbered-paragraph xml-tags. It means it will 
have to render basic lists and it means that the concept of the list is 
written back to the file on saving.
The part where the implementation shows the list is very important to some 
people, while the writing of the exact right tags is important to 
another.
I'm not the one to judge there. And IMO the TC is not one to judge either.

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

Excellent example, this kind of example shows its very hard to define what 
is sufficient in an abstract matter, usable to say "this app is a good 
ODF 1.2 citizen".

Naturally, in your example I fully agree that it is a good citizen. It 
lacks some features (like showing the file) and the end user gets to 
decide if the tool is something he likes based on the feature set it 
supports.

> 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?
>
> 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 think preservation is a unique feature, one in the vast array of 
features that any application has.

Let me explain why I say this, as its a very practical background that 
makes this view not only reasonable, but essential;

Any application that reads an XML file of any size has to make a decision. 
It either uses an internal model that is based on the XML.  This 
typically means the app keeps the DOM tree in memory and works from that.
It can also define its own internal tree. One that gets build by reading 
XML and that gets modified internally after which it gets queried to 
write the XML again.  This internal tree may have very little resemblance 
to the ODF model (and thus the XML).

If an application chooses the second model, its own internal data 
structure, we hit a problem.
What if ODF adds a set of options to tables, but this application doesn't 
know the concept of tables.  Then it becomes very hard, to impossible, 
for this application to store meta data that was tagged on that table.
Afterall, it has no place to store that information in the internal tree.

Tables are just a big example, the real problems tend to be really 
annoying and small. But very diverse.
And every time new features are added to ODF, the application must add 
fields in their datastructure «somehow».

The approach to have a datastructure specific to the application, that may 
or may not have large sections in common with ODF, is the most used one 
for any application larger than a couple hundred lines.

So, to get back to your question;
an ODF implementation does not only have to know about a feature 
like "xml:id" it has to have a data structure to store it and then write 
it back afterwards.  And this limitation means that support for a feature 
is mostly done in two steps.
a) loading + saving is done correctly.
b) it actually renders the feature on screen and allows the user to alter 
it.

So, in that context, yes, preservation is slightly separated.
-- 
Thomas Zander

PGP signature



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