Stephan,
I agree that DocumentView will not allow proper roundtripping (when
the source is a JCR model). At the same time, when the source is an
XML document, DocumentView does (and SystemView does not), and this
was the case in question.
To address Frederic point of view, I think that when it comes to
multivalued properties (which do not really happen often in XML, so
we are dealing with roundtripping from a JCR model), one approach is
to use SystemView (and then maybe transform it in something more
human readable), or to use a SAX handler and the visitor pattern for
a customized output (as in the DocumentViewExportVisitor class).
Of course, I realize that there can be use cases when it is not
practical, and then probably there's no one solution-fits-all.
Alessandro
On Jun 13, 2007, at 8:22 AM, Stefan Guggisberg wrote:
On 6/13/07, Frédéric Esnault <[EMAIL PROTECTED]> 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.
the answer is simple: use system view export.
see http://issues.apache.org/jira/browse/JCR-325 for a
discussion of multi-valued property representation in the
document view xml mapping.
please see also section 6.4.2.5 in the JSR 170 spec.
cheers
stefan
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.
>>
>
