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: Fwd: [office-metadata] Suggested Changes on the Metadata proposal

My earlier response to Michael for more context ...

Begin forwarded message:

> On Jun 29, 2007, at 10:06 AM, Michael Brauer - Sun Germany - ham02 - 
> Hamburg wrote:
>> 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.
> Right.
>> 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 this include attributes?
>> 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?
> The bottomline is, because we move so much of the RDF logic into the 
> package, the xml:id attributes become crucial anchor points. In short, 
> if an application removes, say, the xml:id from a text:meta-field or 
> otherwise causes the URI binding to be invalid, the field will break. 
> It would be bad for interoperability for applications to do this.
> ...
>> 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.
> Well, let's say an application doesn't care about metadata. All they 
> have to do is preserve the files in the package and the xml:ids as is. 
> They need not do any kind of processing.
> I don't see how this is any real burden (?).
>> 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:
> I think the rules should apply to all ODF 1.2 compliant applications. 
> Carving out a separate category of "metadata aware" leaves a large 
> loophole.
> On that basis, perhaps option 1 is preferable, where the language 
> remains "shall." I'd go even further, n fact, and require preservation 
> of all attributes. That makes it a generic requirement that is not 
> specific to metadata, but ensures xml:id preservation.
> Bruce
>> - 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

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