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