RE: [office] Embedded Metadata in <office:document>

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

There is a misunderstanding here.  I am not talking about embedding binary
or non-XML material in an <office:document> element.  My question is only
about the prospect of embedded metadata.  I see no requirement for Base64
encoding at all.

MY QUESTION: Whether the specification of the metadata proposal can make
carrying of the equivalent of metadata.rdf in elements of <office:document>
possible, whether or not supporting <office:document> is unattractive for
other reasons.

 - Dennis

FURTHER ANALYSIS

1. I am only asking where something like a <rdf:rdf> elements might fit,
somewhere under an <office:document> element, that serves the purpose of the
metadata extension in the context of free-standing <office:document> XML
documents.  

2. While removing the <office:document> element might make life simpler, it
is beyond my competence and knowledge of the implementation situation to
propose removal or merely deprecation. I am going to assume, along with you,
that <office:document> will continue to exist in ODF 1.2.  I am not aware
that any proposal for removal is on the table.

3. I don't follow your argument about mapping packages to XML documents with
<office:document> as their root element.  I think it is understood that
there can be package content that is not preservable with a standalone
<office:document>, and no one seems to be disturbed about that.  

4. However, there is a well-defined mapping from an XML <office:document>
document to an ODF package with the same MIME type as in the
<office:document> office:mimetype attribute.  There is also no problem with
preservation of xml:id attributes when mapping from an <office:document>
instance *to* an ODF package instance.  

4. XML documents that appear as subfiles having ODF root elements already
have mappings to <office:document> elements in the ODF specifications.  My
question is whether that technique can be arranged for the case of RDF
metadata too.  This mapping has to do with the correspondence of document
structure, not with a requirement for easy conversion between instances.  

5. I agree that translation of an ODF document *instance* from one form to
the other can require reconciliation of xml:id collisions.  It will
certainly require rewriting of all of the RDF, since the URIs for document
elements will all change when going in either direction.  Whether
implementations make such provision seems to be a decision best left to
implementers, just like a decision to provide first-class support for
standalone <office:document> XML documents.  

Have I narrowed the questions in an useful way?


-----Original Message-----
From: Svante.Schubert@Sun.COM [mailto:Svante.Schubert@Sun.COM] 
http://lists.oasis-open.org/archives/office/200812/msg00181.html
Sent: Wednesday, December 24, 2008 13:14
To: 'OASIS Office'
Cc: dennis.hamilton@acm.org; 'Michael Stahl'
Subject: Re: [office] Embedded Metadata in <office:document>
(http://lists.oasis-open.org/archives/office/200812/msg00179.html)

Hi Dennis,

You are mentioning problems of the ODF flat format being an adequate 
syntax, which the metadata proposal does not intent to fix.
Although I agree that the metadata proposal make those problems more 
obvious.
[ ...]
There is no natural element for carrying XML files.
[ ... ]
Therefore since ODF 1.0 any other user data part of the package is lost 
in the flat format, there is no generic mechanism of mapping.

Than there exist an algorithm how to map the file specific identifier 
(xml:id) from all package files to a single XML document to ensure a 
stable roundtrip among ODF applications.

Finally there is no mime type nor suffix although having a different 
file format (XML instead of ZIP).

 From my view the single <office:document> syntax is boiler plate to 
ODF. It is a burden for implementations by duplicating the format from a 
zip to a single file, without a benefit adding complexities, as you show 
not sufficient solved.
[ ... ]
I would suggest to drop the flat format for the follow up of ODF 1.2 (as 
there are no further proposals for ODF 1.2).
Or does anybody still see a sense in the existence of the file format, 
justifying the effort of the ODF applications?

[ ... ]