Re: [office] Re: [office-metadata] Suggested Changes on the Metadata proposal

[Bruce D'Arcus <bdarcus@gmail.com>]

On Jun 30, 2007, at 7:20 AM, Thomas Zander wrote:

> On Saturday 30 June 2007 13:00:07 Bruce D'Arcus wrote:
>>> 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.
>
> Hmm? How do you come from agreeing two things are the same and then
> suggesting they should be treated separately?
> That just doesn't make sense to me.
> Two issues being the same should be handled the same, don't they?

Sorry, by "these issues" I was meaning metadata on one hand, and the 
general issues of preservation/conformance on the other. I agree that 
while we brought up the latter in the context of the former, they are 
separate issues.

Does that make better sense?

...

>> 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?
>
> That is not your and not my decision to make.

It is the TC's decision as a whole to make though. There are places all 
through the spec that use "shall" language, and a whole lot of others 
that use "should." It's the TC's job to make those distinctions.

> We can just make very clear what the consequences are. And they are 
> very
> obviously going to loose data and functionality. Just like not 
> supporting
> a 'feature' like text:p looses data.
>
> Your questions are valid, just not posted in the right context.
> The questions are valid as they surely will be relevant to the end 
> users.

Yes, and probably application developers as well.

> Which will loose functionality if data is lost.  Your idea to ask this 
> in
> the ODF technical committee(s) is the wrong context.

This is too strong, and frankly a little pedantic.

As I say above, we're writing a spec; discussing the language of the 
spec is absolutely part of that process. If it weren't up for 
discussion, then we'd keep the "shall" language in the proposal. So 
here we're discussing it.

> It is almost never a good idea to make sections mandatory in a 
> specification. If only because
> as soon as you do the applications not implementing the mandatory part
> will still call it ODF, and you get to do police work with all the
> negative market consequences that come with that.
>
> So, to answer your question; an application losing data is not one that
> people will like a lot.
>
> I have to ask you;  how do you think history will unfold if you make 
> this
> part mandatory?
> If you think that suddenly everyone will do it right then you are in 
> for a
> surprise. The world doesn't work like that.
> I can point to issues where OOo is not ODF compliant, and just not
> altering their behavior since it makes sense for them. How does that
> change when you mark something mandatory?

You can at least say its wrong! It is an obvious bug.

> Note the reason I mentioned the testsuite;
> http://testsuite.opendocumentfellowship.org  the reason is that this is
> an excellent tool to tell the world how good or how bad an 
> implementation
> is. We already talked about having an extra metric that specifies how
> well data is retained between load and save.  Its unfortunately not 
> done
> due to lack of manpower.
> A second question for you; do you have doubts that the market can make
> sure ODF compliance becomes a consideration for people choosing their
> tools?

Let me ask the entire group a bigger question: what does it mean for an 
application to say it is "ODF conformant"?

Does it matter -- to users and developers -- that we can answer that 
question with any kind of precision?

Maybe you're right that it's not something that should be tightly 
controlled in the spec and the schema; that we don't provide a binary 
yes/no answer to that question, but rather allow for shades of gray, 
backed up by test suites. I'm fine with that notion.

But then surely it needs to be outlined some place, with some kind of 
blessing of the TC, exactly what those shades of gray are?

I seem to recall this issue of conformance has come up before; but 
would just reiterate it's an important issue.

Bruce