On Jul 1, 2007, at 4:54 PM, wrote:
> To the specific question at hand, I am concerned with the loose use of
> the word "preserve." What exactly does that mean? For example, must
> the xml:id's of the saved document be lexically identical to the read
> document? Or are looser version of equivalence allowed? For example,
> if the id originally is "foo" and then it is saved with the id "bar"
> is that permitted, provided that the structure and referential
> integrity of the id and references are maintained?
From the perspective of the metadata proposal, the xml:id values are
not important because of the binding abstraction. What is important is
that the bindings remain valid (e.g. that it referential integrity be
maintained).
So in your example, if we have:
<text:p xml:id="foo">...</text:p>
.. and then in manifest.rdf the binding:
<odf:Element odf:idref="foo" rdf:about="urn:uuid:u83738u38u380u80u3c"/>
... if an application changes the value of the xml:id to "bar" AND they
update the binding as well ...
<odf:Element odf:idref="bar"
rdf:about="urn:uuid:afdc453c-5dc8-4988-8dab-fc378bd9e73d"/>
... the binding is maintained, and there is no problem. I wouldn't want
to preclude that kind of rewriting. What I don't want to see if for
applications to dump attributes because they don't implement some
particular feature.
> Remember, it will be common for an application to read an XML document
> and convert id's and links into internal runtime representations that
> are not at all similar to the XML. Id/references might be converted
> into C-language pointer references between objects, etc. Then when
> writing out the document, new unique ID's might be generated
> on-the-fly, perhaps in sequential order. This might vary from
> implementation to implementation. Beyond referential integrity, I
> don't know if there is any additional value in saying that a document
> created in KOffice must have identical ID labels when that document is
> later saved in OpenOffice.
I agree.
> We should also note that it is a feature of some programs, such as
> Office 2007, to have a menu item specifically for removing metadata
> from a document, for privacy and security reasons. I don't think we
> want to prevent such an application from claiming conformance.
Agreed also.
> So we need to be need to be very careful how we word this. Perhaps
> something like "Conforming applications that read and write documents
> shall be capable of "preserving" xml:id's, etc." With the proviso
> that "preserving" needs a better definition, this ensures that
> conforming applications support preservation, while also allowing that
> not every mode of use may actually do so, such as when a user deletes
> content or metadata, etc.
Yes, clearly if a user initiatives some action to delete content or
metadata, that's fine. I'm more concerned about silent loss of data.
To give a concrete example:
Awhile back, Elias showed the SC a really compelling demo of some work
his team had done with spreadsheets. The upshot of that in an ODF 1.2
application would be that every spreadsheet cell would be tagged with
metadata attributes that provide an extra layer of information on top
of the spreadsheet.
For an application (let's call it "application A") that does not
support metadata, it would just behave like any other spreadsheet. For
an application that does support metadata (let's call it "application
B"), there might be a whole lot of functionality built on top of that.
But if a user creates this document in application A and sends it to a
colleague using application B: if that second application silently
removes those metadata attributes and the first user gets it back with
that information stripped, that's bad, and should -- I believe -- be
discouraged by this TC.
Bruce
