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

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi,

first of all, it is my understanding that the issue that Svante is 
raising here regarding the usage of shall and should is not that 
applications should get the freedom to remove the xml:id and other 
metadata features whenever they like. Of course, they should keep them 
whenever this is possible and appropriate.

The issue is to find an appropriate language for the things we want to 
achieve. And independent of the issues we are discussing here, this in 
general includes the option to omit a certain language if we believe 
that what we say may be self-evident or given anyway, so that the 
language is not required at all.

Below are few suggestion that may or may not be helpful for addressing 
the metadata related should and shall issues. But before. I would like 
to make some comments:

1. We have to make sure that the language we are choosing is precise, 
and permits reasonable edit operations on documents. Related to xml:ids, 
that means that the language must permit to remove the attribute or to 
change its values if this happens as the result of a user action or a 
machine processing the document.
2. If a document is opened and saved again, we all expect that the 
paragraph content is preserved. The same applies to tables, lists, 
images. etc. Does the specification has a language that enforces
that? No, it doesn't. But we all expect that these features are 
preserved anyway.
But what's different with the xml:id (and metadata in general) that
there is the assumption that it may get removed unless there is a
language that forbids that?
I personally believe that everyone who is interested in ODF is 
interested in implementing as much of ODF as possible (though there may 
of cause be resource or technical restrictions), and this includes 
metadata, regardless what language we use for above features. I further 
believe that we encourage more vendors to implement metadata if we talk 
about the value of implementing them, than we do by making certain 
things mandatory. For that reason, and because it seems not to be too 
easy to find an appropriate language, it would be okay for me if we 
would omit that language at all.
3. The focus of ODF of course are office documents. But there always was 
the assumption that also other kind of applications should be able to 
use ODF. So, if someone develops a small text editor and wishes to 
support ODF to the extend that typical text editors can, this should be 
be possible. Our language should not prohibit that. We should also not 
forget the various ODF plug-in efforts for MS Office or similar ODF 
implementations. They have only limited control of what happens with 
certain information during complex load, edit and save operations within 
MS Office. I'm not sure if they can preserve all metadata and all 
xml:ids under all circumstances in a way that keeps the metadata 
consistent and therefore of value.

Having that said, here are my suggestions. Please do not consider them 
as a proposal. They are only suggestions, and the SC may follow them as 
a whole or partially, or may not.

1. We may move all the metadata related should/shall language into the 
general conformance section. This has the advantage that it is not 
overlooked as easy as it would be if it is in the element and attribute 
description. It further has the advantage that metadata is mentioned at 
a very prominent position.
2. We may introduce the term of a metadata-aware application (or 
something like that), and define conformance definitions along the 
following lines for it:
- A metadata aware ODF implementation *shall* not remove the xml:id 
attributes defined in sections [?] or change its values unless the 
removal or modification is the result of an edit operation caused be the 
user, or a similar action taken by some automatic processing of the 
document.
- [any other requirement that may exist]
3. We may rephrase the above statement for general ODF implementation, 
replacing the *shall* with a *should*:
- An ODF implementation *should* not remove the xml:id attributes 
defined in sections [?] or change its values unless the removal or 
modification is the result of an edit operation caused be the user, or a 
similar action taken by some automatic processing of the document.
4. Some time ago we have discussed whether the question which 
implementation should/shall support what features may be a topic for ODF 
1.3. So we may go with no or only a very limited number of metadata 
related conformance requirements for ODF 1.2, and make a deeper 
discussion part of a more general discussion for ODF 1.3.

Maybe these comments and suggestions are somehow useful.

Best regards

Michael


Bruce D'Arcus wrote:
> Svante,
> 
> I suggest these go to the main TC list. This one, in particular ...
> 
> On 6/27/07, Svante Schubert <Svante.Schubert@sun.com> wrote:
> 
>> VIII) Adjust 'shall' requirement to 'should' for xml:id
>>
>> "All implementations SHALL preserve any xml:id attribute and its value
>> when present on any of the elements listed in 1.4.3."
>>
>> Similar as other standards (e.g. CSS) we should not try to force
>> features by specification, but should let the market sort this out.
>> Moreover the specification could be interpreted that it is even
>> forbidding to delete the xml:id or its value, even when deleting the
>> content, therefore a 'SHOULD' is sufficient.
> 
> ... has major implications. I'm not at all willing to accept this
> without some serious discussion with the entire TC.
> 
> Bruce


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering