See JCR 325. Quote from a previous talk with Jukka Zitting : ----------------------- > It seems very strange to just ignore the multivalued properties. It gives > completely wrong documents.
I see your point. Earlier on we disabled the multivalue export in docview because people were getting confused when their exports would not roundtrip properly. BR, Jukka Zitting ----------------------- My multivalued reference properties are not exported. Frédéric Esnault -----Message d'origine----- De : Alessandro Bologna [mailto:[EMAIL PROTECTED] Envoyé : mercredi 13 juin 2007 14:17 À : [email protected] Objet : Re: Importing and Exporting XML Quoting from the code comments for escapeValue(): * Returns the document view representation of the given property. * Multiple values are combined into a space-separated list of * space-escaped string values, binary values are encoded using the * Base64 encoding, and other values are simply returned using their * default string representation. Alessandro. On Jun 13, 2007, at 8:02 AM, Frédéric Esnault wrote: > Of course, in wolly's case, it doesn't really matter, but > jackrabbit is not supposed to be a "one use product", but a > generic JCR. And I just tried my own use case, which is not a very > odd case, where I have some contracts referencing contractors by > reference. And with a document view, I loose these references, the > contract managers also multivalued, and so on. > > I don't know how you export references, because I can't. > > Frédéric Esnault > > -----Message d'origine----- > De : Alessandro Bologna [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 13 juin 2007 13:55 > À : [email protected] > Objet : Re: Importing and Exporting XML > > Frederic, > > Some multivalued properties are handled correctly (say for instance > multivalued references are exported as space separated lists of > references in an attribute), and in some other cases it's still > possible to do an encoding of the values, so that they can be > represented inside an XML attribute. But I agree that in some cases > it's really not practical (say binary properties...) because the XML > that would result would probaby be not very much readable. > > But in Wolly's (or Phil's?) case, the problem is to round-trip XML, > which does not have multi-valued properties to start with (so it > doesn't really matter, does it?) > > Alessandro. > > > On Jun 13, 2007, at 7:43 AM, Frédéric Esnault wrote: > >> What about the multivalued properties not included in the export? >> The exported document, even if it's modified by XSL/java is still >> incorrect, as the multivalued properties are simply ignored. >> >> I know the JSR 170 spec leaves the right to do so, but imo it >> creates an incoherent export. I don't think anyone even think about >> the possibility that some properties are just ignored when doing an >> export from a CMS... >> >> Frédéric Esnault - Ingénieur R&D >> >> >> -----Message d'origine----- >> De : Alessandro Bologna [mailto:[EMAIL PROTECTED] >> Envoyé : mercredi 13 juin 2007 13:34 >> À : [email protected] >> Objet : Re: Importing and Exporting XML >> >> Yes. Two ways: >> 1. Java way: use the DocumentViewExportVisitor and override the >> includeProperty() method (simply return false if the property has a >> namespace you don't want). >> >> 2. XML way: use an XSLT identity transformation and add rules for >> removing any attribute that you don't want. >> >> Alessandro >> >> >> On Jun 13, 2007, at 7:20 AM, woolly wrote: >> >>> >>> Thanks for replying... >>> >>> If I have a document like this: >>> <?xml version="1.0" encoding="UTF-8"?> >>> <cheeses> >>> <cheese>edam</cheese> >>> <cheese>lancashire</cheese> >>> <cheese>cheshire</cheese> >>> <cheese>stilton</cheese> >>> </cheeses> >>> >>> ...and I import it using: >>> fis = new FileInputStream(inputFile); >>> session.importXML(node.getPath(), fis, >>> ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW); >>> fis.close(); >>> >>> ...when I export it using: >>> out = new FileOutputStream(outputFile); >>> session.exportDocumentView(node.getPath(), out, true, false); >>> >>> ...I get: >>> >>> <?xml version="1.0" encoding="UTF-8"?> >>> <cheeses xmlns:dc="http://www.purl.org/dc/elements/1.1/"; >>> xmlns:jcr="http://www.jcp.org/jcr/1.0"; >>> xmlns:nt="http://www.jcp.org/jcr/nt/1.0"; >>> xmlns:sv="http://www.jcp.org/jcr/sv/1.0"; >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; >>> xmlns:xs="http://www.w3.org/2001/XMLSchema"; >>> xmlns:fn="http://www.w3.org/2005/xpath-functions"; >>> xmlns:fn_old="http://www.w3.org/2004/10/xpath-functions"; >>> xmlns:mix="http://www.jcp.org/jcr/mix/1.0"; xmlns:rep="internal" >>> jcr:primaryType="nt:unstructured"> >>> <cheese jcr:primaryType="nt:unstructured">edam</cheese> >>> <cheese jcr:primaryType="nt:unstructured">lancashire</cheese> >>> <cheese jcr:primaryType="nt:unstructured">cheshire</cheese> >>> <cheese jcr:primaryType="nt:unstructured">stilton</cheese> >>> </cheeses> >>> >>> ...is there any way to just get the original document out? >>> >>> Thanks, >>> >>> Phil. >>> >>> >>> Julian Reschke wrote: >>>> >>>> woolly wrote: >>>>> Surely then I would want to use some form of document view, >>>>> then, in >>>>> order to >>>>> get back the original document I put in? >>>> >>>> Yes (contrary to what you've been told here before). >>>> >>>> There are known limitations with the document view (such as >>>> restrictions >>>> with multivalued props). But the thing you complained about was >>>> something else; maybe unneeded attributes in the jcr namespace? >>>> Could >>>> you be a bit more specific about that problem? >>>> >>>> Best regards, Julian >>>> >>>> >>>> >>> >>> -- >>> View this message in context: http://www.nabble.com/Importing-and- >>> Exporting-XML-tf3908819.html#a11097246 >>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com. >>> >> >
