(In reply to comment #0)
> Created attachment 77589 [details]
> Proposed patch to add rdf read/write support in ods
> 
> AOO 3.4 supports RDF read/write and statement on some document element of
> Writer. 
> But on Calc ODS document does not support RDF. If it supports read/write of
> RDF in odf file filter at least, extensions can be use it to store data in
> it. 

Very nice feature :)
Can you please upload some macro or script to test the feature?

Created attachment 77600 [details]
Document including test macro

(In reply to comment #1)
> Very nice feature :)
> Can you please upload some macro or script to test the feature?
Sorry, I forgot to attach test file. 

Open attached file, there are three buttons on the spreadsheet. 
- Push "Store" button, it stores values from Sheet1.A1 and A2 in rdf file. Store the document through File - Save.
- Push "Read" button, it reads values from RDF file, it should be shown like: 
Sheet1.A1:value:100 \n Sheet1.A1:value:ABC for initial state of the sheet. 
The order of these values are not important.
- In the ods document, user defined RDF file should be placed in the place specified by addMetadataFile method. 
In this macro, it should be stored in mytools_calc_watchingwindow/settings.rdf.
- Push "Remove" button to remove RDF file created by this macro. Store the document from File - Save. The rdf file should be gone from the ods file.

And manifest.rdf file is created by the office. It can be seen in ODT file now too. 
The attached macro can be executed on Writer document and it stores same value in rdf. RDF file should be stored in the same path in the odf file.

And also, I used this function in my WatchingWindow extension recently released: 
http://extensions.openoffice.org/en/node/5439

(In reply to comment #2)
> And also, I used this function in my WatchingWindow extension recently
> released: 
> http://extensions.openoffice.org/en/node/5439

It seems you are not making the selection persistent. As I doubt this is going to be considered to be included in AOO 3.4.1, you can use as a workaround the embed API together with the rdf API to embed an RDF file and then pass the stream to XRepository::import/exportGraph().

I'll attach a sample document, for those who want to use RDF in Calc/Impress/Draw/Math.

Created attachment 77608 [details]
Document with macros showing how to embed RDF files

(In reply to comment #0)
> Proposed patch to add rdf read/write support in ods
> 
> AOO 3.4 supports RDF read/write and statement on some document element of
> Writer. 
> But on Calc ODS document does not support RDF. If it supports read/write of
> RDF in odf file filter at least, extensions can be use it to store data in
> it. 
> 
> I wrote patch for ods filter according to filter of odt,
> main/sw/source/filter/xml/wrtxml.cxx and main/sw/source/filter/xml/swxml.cxx.

The patch works fine, it needs only to consider two points:
a) when only the styles are requested, RDF can be ignored
b) when loading/storing the metadata from/to the storage, the exceptions should be taken into account for the function final return value

You can see both points in 
main/sw/source/filter/xml/wrtxml.cxx 
main/sw/source/filter/xml/swxml.cxx

For (a), take into account the "OrganizerMode", and surround the code with an if-statement ( if (!bStylesOnly) ). You can debug this "OrganizerMode":
- save a spreadsheet document as template
- go to the menu "File" - "Templates" - "Organize..."
- set a break point on ScXMLImportWrapper::Import
- double click on your template
This will try to import only the styles from the file, and will list them in the  "Template Management" dialog. With the current patch, you'll see that bStylesOnly is true, but the RDF metadata is read. See in main/sw/source/filter/xml/swxml.cxx the 
if (!(IsOrganizerMode() || ...), this is there to save us from importing the RDF metdata in this case where it isn't relevant.

For (b), we shouldn't ignore the exceptions thrown by loadMetadataFromStorage/storeMetadataToStorage . Here too look at the code in main/sw/source/filter/xml/ 
While the css::lang::WrappedTargetException can be marked as an ERROR with SCERR_IMPORT_UNKNOWN, I'm not sure there is a flag  in sc/inc/scerrors.hxx to mark a WARNING when losing the RDF metadata (I mean, to flag a data/feature lost that is a WARNING, but not an ERROR). If you find that you need to add new defines in that file, flag them with the proper WARNING flag (ERRCODE_WARNING_MASK).

Created attachment 77867 [details]
Patch with checking bStylesOnly and error for import

(In reply to comment #5)
> The patch works fine, it needs only to consider two points:
> a) when only the styles are requested, RDF can be ignored
Added.
> b) when loading/storing the metadata from/to the storage, the exceptions
> should be taken into account for the function final return value
I introduced SCWARN_IMPORT_FEATURES_LOST and its string resource for import. 
But ScXMLImportWrapper::Export(sal_Bool bStylesOnly) method does not have 
the way to return back error/warning code. 
I need to change the method to it. When I return sal_True from the method, 
I makes error to faled to store the file contents, not warning. 
The attached patch do not have making warning for Export method. 
I need more time to introduce the way of warning for the Export method.

@hanya: sorry for the delay, I updated my system from Fedora 16 to Fedora 17 and my build environment got completely broken (rev. 1348593, 1348595, 1348596).

Committed as Revision 1348605

@hanya: Thanks for your contribution.

(In reply to comment #6)
> Created attachment 77867 [details]
> Patch with checking bStylesOnly and error for import
> 
> (In reply to comment #5)
> > The patch works fine, it needs only to consider two points:
> > a) when only the styles are requested, RDF can be ignored
> Added.
> > b) when loading/storing the metadata from/to the storage, the exceptions
> > should be taken into account for the function final return value
> I introduced SCWARN_IMPORT_FEATURES_LOST and its string resource for import. 
> But ScXMLImportWrapper::Export(sal_Bool bStylesOnly) method does not have 
> the way to return back error/warning code. 
> I need to change the method to it. When I return sal_True from the method, 
> I makes error to faled to store the file contents, not warning. 
> The attached patch do not have making warning for Export method. 
> I need more time to introduce the way of warning for the Export method.

There are different ways of doing this, though I find more consistent how it's done in sw than in sc (you could change the return value from boolean to error code and then check it, see inline FASTBOOL IsError( sal_uLong nErr ) in sw/inc/swerror.h and its uses.

Any way the patch is very good with the changes you made, so I committed it. If you find time to do this enhancement, reopen the issue when the patch is ready.

(In reply to comment #8)
> Any way the patch is very good with the changes you made, so I committed it.
> If you find time to do this enhancement, reopen the issue when the patch is
> ready.
Sure, thanks to commit.

Verify fixed on trunk rev.1351249 with the sample file in this bug.
Suggest close this bug.

Close it.