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

On Jul 1, 2007, at 4:54 PM, robert_weir@us.ibm.com 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 

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" 

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


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