Re: [office-metadata] comments on latest draft

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

Hi Bruce,

Bruce D'Arcus wrote:
> 
> On Mar 7, 2007, at 8:56 AM, Svante Schubert wrote:
> 
>>> 2. "Applications that read and write document should preserve all 
>>> metadata files."
>>>
>>> Sorry, that's not good enough. All ODF 1.2 compliant applications 
>>> "shall" preserve the files.
>> In ODF features are in general marked as "may" or "should" and not as 
>> "shall".
> 
> Except that I see the word "shall" at least three times on that page. It 
> is a striking contrast to then say preserving the files is a "should."

I do understand your concerns, but also think that "should" is already a 
very strong statement - much stronger than the statements we have for 
other features.

But let's assume we say *shall* instead. The consequence this has is 
that an application then must preserve the metadata even if it has 
modified the document, and therefore does not know whether the metadata 
is still consistent. Since this may lead to inconsistent documents, its 
probably not what we want. What about the following:

"Applications that read and write documents *shall not* remove metadata 
files if no modification have been made to a document."

or a little bit stronger:

"Applications that read and write documents *shall* preserve metadata 
files as long as no modification have been to the document that let it 
appear likely that the metadata files are not valid any longer."

I'm sure the later could be phrased better, but the intention should 
become clear:-)

Michael





> 
>> We can hardly make an exception for metadata, especially as we have no 
>> consistency concept so far, simply keeping them won't be sufficient, 
>> sometimes a removal might be even better.
> 
> Under what conditions would it be OK for an application to open a 
> metadata enhanced file and remove the metadata per se? That seems a 
> recipe for big problems?
> 
>>> 3.  Question: do we want to offer suggestions on RDF/XML 
>>> serialization to make it friendlier to XML tools?
>> Good point. We shall we bring this up on today's call if we agree in 
>> giving a serialization suggestion.
>> For instance, a limitation of RDF/XML attribute / element 
>> changeability would be helpful.
> 
> I'd just suggest a generic suggestion, as I've mentioned before, that 
> the RDF/XML be serialized using what is often called the "abbreviated" 
> system: all properties wrapped in a common rdf:about wrapper, properties 
> represented as elements, and so forth.
> 
>>> Section 1.1.1
>>> =============
>>>
>>> 4. The meta:category example should use the new URI for vCard (the 
>>> older one is being deprecated).
>>>
>>> <http://www.w3.org/2006/vcard/ns#>
>> It was not a deprecated link of vCard, but a link to a vCard encoding 
>> in RDF/XML.
> 
> Yes, I know. It's that old version is rather ugly, and so better to 
> point instead to something more up-to-date.
> 
> ...
> 
>>> 8. First sentence is unclear.
>>
>> As there was no suggested wording, I changed it to:
>>
>> "The xml:id attribute is allowed on the set of OpenDocument elements 
>> described below. The attribute gives the element a unique 
>> identification in the XML file and works as an anchor to create 
>> references to the element."
> 
> Good.
> 
>>> Section 1.2.2
>>> =============
>>>
>>> 10. The list item 1 is unclear.
>> I will discuss this with Patrick. Have you a suggestion?
> 
> No. Sorry; busy.
> 
>>> 11. The list item 2 might include reference to the fact that the 
>>> meta:label may do more than just display, but might offer other 
>>> functionality?
>> I am not sure if I understand, what you mean. Have you got a suggested 
>> wording?
> 
> Maybe Patrick has an idea, but I'm just noting that this can potentially 
> be used for more than just "creating content." Imagine if I have a label 
> that refers to a vCard for example. Maybe I can right-click and send 
> that person an email or schedule an appointment. Just saying you tweak 
> the language so developers can see that.
> 
> 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