You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by woolly <p....@lbs-ltd.com> on 2007/06/12 19:05:21 UTC
Importing and Exporting XML
Hi all,
Is it possible to import xml into a node, and then export that xml back out
to have the same xml-equivalent file? At the moment I'm trying:
fis = new FileInputStream(inputFile);
session.importXML(node.getPath(), fis,
ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
fis.close();
// followed by....
out = new FileOutputStream(outputFile);
session.exportDocumentView(node.getPath(), out, true, false);
The difference between inputFile and outputFile seems to be that there are
some additional jcr specific attributes. Is this necessary?
What I'm really trying to do is manage an xml document (eventually many xml
documents), allow people to make changes to only certain parts of it,
versioning those parts and using other JackRabbit features. Is this the kind
of thing that JackRabbit was intended for? Or should I just load the xml
document in as a property of a node and deal with the other things myself?
Thanks for any help,
Phil.
--
View this message in context: http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11082908
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Importing and Exporting XML
Posted by woolly <p....@lbs-ltd.com>.
Alessandro Bologna wrote:
>
> Phil,
>
> it looks a bit better already...
> Those namespace are there because they are added in with
> handler.StartPrefixMapping() in the visit method, and they are needed
> because the method is generic, and all it does is to add all the
> namespaces
> that are declared in the current repository (some of those that you list
> are
> not really jcr related and I suspect that were added when you imported
> other
> XML documents into it).
>
Does JackRabbit store the namespaces related to each node, or are they
stored in some general location? If they are stored with the node then I may
be able to write something to find all the namespaces required for a certain
branch when I export from that node......?
> The namespace declaration is not an attribute, and that's why you cannot
> remove them in the includeProperty method.
>
> I am sure that there could be other ways too, but one solution is to use a
> processing chain on the output (SAX transformers are really meant for
> that)
>
Sorry, what do you mean by a processing chain? I'm more of a DOM kind-a-guy
usually....
> and use this XSLT to strip all the namespaces:
>
> <xsl:template match="*">
> <xsl:element name="{local-name()}" namespace="">
> <xsl:copy-of select="@*"/>
> <xsl:apply-templates />
> </xsl:element>
> </xsl:template>
>
> Alessandro
>
>
>
>
>
>
> On 6/14/07, woolly <p....@lbs-ltd.com> wrote:
>>
>>
>> Hi there,
>>
>> I've got a hold of DocumentViewExportVisitor from the contrib section as
>> suggested, and added the jar files xercesImpl-2.8.1.jar and
>> commons-codec-1.3.jar that it appeared to require. I then subclassed
>> DocumentViewExportVisitor like this:
>>
>> public class CleanDocumentViewExportVisitor extends
>> DocumentViewExportVisitor
>> {
>>
>> public CleanDocumentViewExportVisitor(ContentHandler handler,
>> boolean
>> skipBinary, boolean noRecurse)
>> {
>> super(handler, skipBinary, noRecurse);
>> }
>>
>> @Override
>> protected boolean includeProperty(Property property) throws
>> RepositoryException
>> {
>> return !property.getName().startsWith("jcr:");
>> }
>> }
>>
>> .....and exported my document using this:
>>
>> SAXTransformerFactory factory = (SAXTransformerFactory)
>> SAXTransformerFactory.newInstance();
>> TransformerHandler handler = factory.newTransformerHandler();
>> handler.setResult(new StreamResult(output));
>> node.accept(new CleanDocumentViewExportVisitor(handler, skipBinary,
>> noRecurse));
>>
>> ....but I end up with the following (based on my original <cheeses>
>> example):
>>
>> <?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">
>> <cheese>edam</cheese>
>> <cheese>lancashire</cheese>
>> <cheese>cheshire</cheese>
>> <cheese>stilton</cheese>
>> </cheeses>
>>
>> Why does JCR need to add all these namespaces to my root node on export?
>> They're not shown as properties when they are stored in the repository,
>> and
>> I can't affect them as they are never passed through includeProperty().
>>
>> Thanks
>>
>> Phil.
>>
>>
>> Alessandro Bologna wrote:
>> >
>> > Jukka,
>> >
>> > yes no problems. I will file it as a bug. And yes, I think that
>> > exportVisitor, providing a simple way to customize the XML
>> > presentation of a JCR subtree is quite useful for a RESTful XSLT
>> > presentation layer of a JCR. In fact, that's why I use it.
>> >
>> > Alessandro
>> >
>> >
>> > On Jun 13, 2007, at 9:25 AM, Jukka Zitting wrote:
>> >
>> >> Hi,
>> >>
>> >> On 6/13/07, Alessandro Bologna <al...@gmail.com> wrote:
>> >>> Just be sure to fix the line in escapeName(), otherwise you will not
>> >>> like the document that much...
>> >>>
>> >>> >if ((i == 0) ? XMLChar.isNCNameStart(ch) :
>> >>> XMLChar.isNCName(ch)) {
>> >>> <if ((i == 0) ? !XMLChar.isNCNameStart(ch) : !
>> >>> XMLChar.isNCName(ch)) {
>> >>>
>> >>> The test should be with a not (!).
>> >>> I forgot to mention that in my previous reply, and maybe the project
>> >>> owner can fix it?
>> >>
>> >> Sure, thanks for catching that! Could you file a a bug report for
>> >> that?
>> >>
>> >> If there's interest in the ExportVisitor functionality, we could make
>> >> it available in jackrabbit-jcr-commons in the 1.4 release.
>> >>
>> >> BR,
>> >>
>> >> Jukka Zitting
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11119815
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11123015
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
Phil,
it looks a bit better already...
Those namespace are there because they are added in with
handler.StartPrefixMapping() in the visit method, and they are needed
because the method is generic, and all it does is to add all the namespaces
that are declared in the current repository (some of those that you list are
not really jcr related and I suspect that were added when you imported other
XML documents into it).
The namespace declaration is not an attribute, and that's why you cannot
remove them in the includeProperty method.
I am sure that there could be other ways too, but one solution is to use a
processing chain on the output (SAX transformers are really meant for that)
and use this XSLT to strip all the namespaces:
<xsl:template match="*">
<xsl:element name="{local-name()}" namespace="">
<xsl:copy-of select="@*"/>
<xsl:apply-templates />
</xsl:element>
</xsl:template>
Alessandro
On 6/14/07, woolly <p....@lbs-ltd.com> wrote:
>
>
> Hi there,
>
> I've got a hold of DocumentViewExportVisitor from the contrib section as
> suggested, and added the jar files xercesImpl-2.8.1.jar and
> commons-codec-1.3.jar that it appeared to require. I then subclassed
> DocumentViewExportVisitor like this:
>
> public class CleanDocumentViewExportVisitor extends
> DocumentViewExportVisitor
> {
>
> public CleanDocumentViewExportVisitor(ContentHandler handler,
> boolean
> skipBinary, boolean noRecurse)
> {
> super(handler, skipBinary, noRecurse);
> }
>
> @Override
> protected boolean includeProperty(Property property) throws
> RepositoryException
> {
> return !property.getName().startsWith("jcr:");
> }
> }
>
> .....and exported my document using this:
>
> SAXTransformerFactory factory = (SAXTransformerFactory)
> SAXTransformerFactory.newInstance();
> TransformerHandler handler = factory.newTransformerHandler();
> handler.setResult(new StreamResult(output));
> node.accept(new CleanDocumentViewExportVisitor(handler, skipBinary,
> noRecurse));
>
> ....but I end up with the following (based on my original <cheeses>
> example):
>
> <?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">
> <cheese>edam</cheese>
> <cheese>lancashire</cheese>
> <cheese>cheshire</cheese>
> <cheese>stilton</cheese>
> </cheeses>
>
> Why does JCR need to add all these namespaces to my root node on export?
> They're not shown as properties when they are stored in the repository,
> and
> I can't affect them as they are never passed through includeProperty().
>
> Thanks
>
> Phil.
>
>
> Alessandro Bologna wrote:
> >
> > Jukka,
> >
> > yes no problems. I will file it as a bug. And yes, I think that
> > exportVisitor, providing a simple way to customize the XML
> > presentation of a JCR subtree is quite useful for a RESTful XSLT
> > presentation layer of a JCR. In fact, that's why I use it.
> >
> > Alessandro
> >
> >
> > On Jun 13, 2007, at 9:25 AM, Jukka Zitting wrote:
> >
> >> Hi,
> >>
> >> On 6/13/07, Alessandro Bologna <al...@gmail.com> wrote:
> >>> Just be sure to fix the line in escapeName(), otherwise you will not
> >>> like the document that much...
> >>>
> >>> >if ((i == 0) ? XMLChar.isNCNameStart(ch) :
> >>> XMLChar.isNCName(ch)) {
> >>> <if ((i == 0) ? !XMLChar.isNCNameStart(ch) : !
> >>> XMLChar.isNCName(ch)) {
> >>>
> >>> The test should be with a not (!).
> >>> I forgot to mention that in my previous reply, and maybe the project
> >>> owner can fix it?
> >>
> >> Sure, thanks for catching that! Could you file a a bug report for
> >> that?
> >>
> >> If there's interest in the ExportVisitor functionality, we could make
> >> it available in jackrabbit-jcr-commons in the 1.4 release.
> >>
> >> BR,
> >>
> >> Jukka Zitting
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11119815
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: Importing and Exporting XML
Posted by woolly <p....@lbs-ltd.com>.
Hi there,
I've got a hold of DocumentViewExportVisitor from the contrib section as
suggested, and added the jar files xercesImpl-2.8.1.jar and
commons-codec-1.3.jar that it appeared to require. I then subclassed
DocumentViewExportVisitor like this:
public class CleanDocumentViewExportVisitor extends
DocumentViewExportVisitor
{
public CleanDocumentViewExportVisitor(ContentHandler handler, boolean
skipBinary, boolean noRecurse)
{
super(handler, skipBinary, noRecurse);
}
@Override
protected boolean includeProperty(Property property) throws
RepositoryException
{
return !property.getName().startsWith("jcr:");
}
}
.....and exported my document using this:
SAXTransformerFactory factory = (SAXTransformerFactory)
SAXTransformerFactory.newInstance();
TransformerHandler handler = factory.newTransformerHandler();
handler.setResult(new StreamResult(output));
node.accept(new CleanDocumentViewExportVisitor(handler, skipBinary,
noRecurse));
....but I end up with the following (based on my original <cheeses>
example):
<?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">
<cheese>edam</cheese>
<cheese>lancashire</cheese>
<cheese>cheshire</cheese>
<cheese>stilton</cheese>
</cheeses>
Why does JCR need to add all these namespaces to my root node on export?
They're not shown as properties when they are stored in the repository, and
I can't affect them as they are never passed through includeProperty().
Thanks
Phil.
Alessandro Bologna wrote:
>
> Jukka,
>
> yes no problems. I will file it as a bug. And yes, I think that
> exportVisitor, providing a simple way to customize the XML
> presentation of a JCR subtree is quite useful for a RESTful XSLT
> presentation layer of a JCR. In fact, that's why I use it.
>
> Alessandro
>
>
> On Jun 13, 2007, at 9:25 AM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On 6/13/07, Alessandro Bologna <al...@gmail.com> wrote:
>>> Just be sure to fix the line in escapeName(), otherwise you will not
>>> like the document that much...
>>>
>>> >if ((i == 0) ? XMLChar.isNCNameStart(ch) :
>>> XMLChar.isNCName(ch)) {
>>> <if ((i == 0) ? !XMLChar.isNCNameStart(ch) : !
>>> XMLChar.isNCName(ch)) {
>>>
>>> The test should be with a not (!).
>>> I forgot to mention that in my previous reply, and maybe the project
>>> owner can fix it?
>>
>> Sure, thanks for catching that! Could you file a a bug report for
>> that?
>>
>> If there's interest in the ExportVisitor functionality, we could make
>> it available in jackrabbit-jcr-commons in the 1.4 release.
>>
>> BR,
>>
>> Jukka Zitting
>
>
>
--
View this message in context: http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11119815
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Importing and Exporting XML
Posted by Stefan Guggisberg <st...@gmail.com>.
hi alessandro,
On 6/13/07, Alessandro Bologna <al...@gmail.com> wrote:
> 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.
i see, thanks for the clarification. please note that you'll never get
true bona fide
xml roundtripping. the document view representation is lossy also wrt
to the original
xml document (e.g. scoped namespace declarations, formatting etc are lost).
>
> 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.
i agree. using DocumentViewExportVisitor is imo the best solution.
cheers
stefan
>
> Alessandro
>
>
>
>
> On Jun 13, 2007, at 8:22 AM, Stefan Guggisberg wrote:
>
> > On 6/13/07, Frédéric Esnault <fe...@legisway.com> 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:alessandro.bologna@gmail.com]
> >> Envoyé: mercredi 13 juin 2007 13:55
> >> À: users@jackrabbit.apache.org
> >> 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:alessandro.bologna@gmail.com]
> >> > Envoyé : mercredi 13 juin 2007 13:34
> >> > À : users@jackrabbit.apache.org
> >> > 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.
> >> >>
> >> >
> >>
> >>
>
>
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
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 <fe...@legisway.com> 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:alessandro.bologna@gmail.com]
>> Envoyé: mercredi 13 juin 2007 13:55
>> À: users@jackrabbit.apache.org
>> 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:alessandro.bologna@gmail.com]
>> > Envoyé : mercredi 13 juin 2007 13:34
>> > À : users@jackrabbit.apache.org
>> > 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.
>> >>
>> >
>>
>>
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
Frederic,
I agree with you that in your case (I read your previous posts) you
had to use SystemView: your problem was to import and export a JCR
model using XML as a medium. But the subject of this thread is
Importing and Exporting XML, and to suggest to Phil (Woolly) to use
SystemView may be a bit misleading, because you put cheese and you
get nodes...
Alessandro
On Jun 13, 2007, at 8:25 AM, Frédéric Esnault wrote:
> I AM using system view export, as it seems this is the only way ;)
>
> Frédéric Esnault
>
>
> -----Message d'origine-----
> De : Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Envoyé : mercredi 13 juin 2007 14:23
> À : users@jackrabbit.apache.org
> Objet : Re: Importing and Exporting XML
>
> On 6/13/07, Frédéric Esnault <fe...@legisway.com> 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:alessandro.bologna@gmail.com]
>> Envoyé: mercredi 13 juin 2007 13:55
>> À: users@jackrabbit.apache.org
>> 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:alessandro.bologna@gmail.com]
>>> Envoyé : mercredi 13 juin 2007 13:34
>>> À : users@jackrabbit.apache.org
>>> 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.
>>>>
>>>
>>
>>
RE: Importing and Exporting XML
Posted by Frédéric Esnault <fe...@legisway.com>.
I AM using system view export, as it seems this is the only way ;)
Frédéric Esnault
-----Message d'origine-----
De : Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Envoyé : mercredi 13 juin 2007 14:23
À : users@jackrabbit.apache.org
Objet : Re: Importing and Exporting XML
On 6/13/07, Frédéric Esnault <fe...@legisway.com> 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:alessandro.bologna@gmail.com]
> Envoyé: mercredi 13 juin 2007 13:55
> À: users@jackrabbit.apache.org
> 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:alessandro.bologna@gmail.com]
> > Envoyé : mercredi 13 juin 2007 13:34
> > À : users@jackrabbit.apache.org
> > 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.
> >>
> >
>
>
Re: Importing and Exporting XML
Posted by Stefan Guggisberg <st...@gmail.com>.
On 6/13/07, Frédéric Esnault <fe...@legisway.com> 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:alessandro.bologna@gmail.com]
> Envoyé: mercredi 13 juin 2007 13:55
> À: users@jackrabbit.apache.org
> 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:alessandro.bologna@gmail.com]
> > Envoyé : mercredi 13 juin 2007 13:34
> > À : users@jackrabbit.apache.org
> > 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.
> >>
> >
>
>
RE: Importing and Exporting XML
Posted by Frédéric Esnault <fe...@legisway.com>.
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:alessandro.bologna@gmail.com]
Envoyé : mercredi 13 juin 2007 14:17
À : users@jackrabbit.apache.org
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:alessandro.bologna@gmail.com]
> Envoyé : mercredi 13 juin 2007 13:55
> À : users@jackrabbit.apache.org
> 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:alessandro.bologna@gmail.com]
>> Envoyé : mercredi 13 juin 2007 13:34
>> À : users@jackrabbit.apache.org
>> 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.
>>>
>>
>
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
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:alessandro.bologna@gmail.com]
> Envoyé : mercredi 13 juin 2007 13:55
> À : users@jackrabbit.apache.org
> 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:alessandro.bologna@gmail.com]
>> Envoyé : mercredi 13 juin 2007 13:34
>> À : users@jackrabbit.apache.org
>> 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.
>>>
>>
>
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
Jukka,
yes no problems. I will file it as a bug. And yes, I think that
exportVisitor, providing a simple way to customize the XML
presentation of a JCR subtree is quite useful for a RESTful XSLT
presentation layer of a JCR. In fact, that's why I use it.
Alessandro
On Jun 13, 2007, at 9:25 AM, Jukka Zitting wrote:
> Hi,
>
> On 6/13/07, Alessandro Bologna <al...@gmail.com> wrote:
>> Just be sure to fix the line in escapeName(), otherwise you will not
>> like the document that much...
>>
>> >if ((i == 0) ? XMLChar.isNCNameStart(ch) :
>> XMLChar.isNCName(ch)) {
>> <if ((i == 0) ? !XMLChar.isNCNameStart(ch) : !
>> XMLChar.isNCName(ch)) {
>>
>> The test should be with a not (!).
>> I forgot to mention that in my previous reply, and maybe the project
>> owner can fix it?
>
> Sure, thanks for catching that! Could you file a a bug report for
> that?
>
> If there's interest in the ExportVisitor functionality, we could make
> it available in jackrabbit-jcr-commons in the 1.4 release.
>
> BR,
>
> Jukka Zitting
Re: Importing and Exporting XML
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/13/07, Alessandro Bologna <al...@gmail.com> wrote:
> Just be sure to fix the line in escapeName(), otherwise you will not
> like the document that much...
>
> >if ((i == 0) ? XMLChar.isNCNameStart(ch) : XMLChar.isNCName(ch)) {
> <if ((i == 0) ? !XMLChar.isNCNameStart(ch) : !XMLChar.isNCName(ch)) {
>
> The test should be with a not (!).
> I forgot to mention that in my previous reply, and maybe the project
> owner can fix it?
Sure, thanks for catching that! Could you file a a bug report for that?
If there's interest in the ExportVisitor functionality, we could make
it available in jackrabbit-jcr-commons in the 1.4 release.
BR,
Jukka Zitting
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
Have you tried the DocumentViewExportVisitor from the contrib (I sent
the link before)? It does export references, and you can always
customize the code to suit your needs.
Just be sure to fix the line in escapeName(), otherwise you will not
like the document that much...
>if ((i == 0) ? XMLChar.isNCNameStart(ch) : XMLChar.isNCName(ch)) {
<if ((i == 0) ? !XMLChar.isNCNameStart(ch) : !XMLChar.isNCName(ch)) {
The test should be with a not (!).
I forgot to mention that in my previous reply, and maybe the project
owner can fix it?
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:alessandro.bologna@gmail.com]
> Envoyé : mercredi 13 juin 2007 13:55
> À : users@jackrabbit.apache.org
> 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:alessandro.bologna@gmail.com]
>> Envoyé : mercredi 13 juin 2007 13:34
>> À : users@jackrabbit.apache.org
>> 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.
>>>
>>
>
RE: Importing and Exporting XML
Posted by Frédéric Esnault <fe...@legisway.com>.
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:alessandro.bologna@gmail.com]
Envoyé : mercredi 13 juin 2007 13:55
À : users@jackrabbit.apache.org
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:alessandro.bologna@gmail.com]
> Envoyé : mercredi 13 juin 2007 13:34
> À : users@jackrabbit.apache.org
> 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.
>>
>
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
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:alessandro.bologna@gmail.com]
> Envoyé : mercredi 13 juin 2007 13:34
> À : users@jackrabbit.apache.org
> 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.
>>
>
RE: Importing and Exporting XML
Posted by Frédéric Esnault <fe...@legisway.com>.
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:alessandro.bologna@gmail.com]
Envoyé : mercredi 13 juin 2007 13:34
À : users@jackrabbit.apache.org
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.
>
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
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.
>
Re: Importing and Exporting XML
Posted by woolly <p....@lbs-ltd.com>.
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.
Re: Importing and Exporting XML
Posted by Julian Reschke <ju...@gmx.de>.
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
RE: Importing and Exporting XML
Posted by woolly <p....@lbs-ltd.com>.
Surely then I would want to use some form of document view, then, in order to
get back the original document I put in?
Frédéric Esnault wrote:
>
> Yes the system view is very different from the document view, which is
> more "business" and/or "human readable". The system view shows your node
> information in a system point of view, which means in a jackrabbit
> architecture view.
>
> The information you expect to see (ie node name, property values) are
> mixed in a huge amount of system information about the node, its type, its
> mixins, its system properties (mandatory, multivalued....)
>
> It may be quite funky, as you say.
>
> Frédéric Esnault - Ingénieur R&D
>
> -----Message d'origine-----
> De : woolly [mailto:p.barr@lbs-ltd.com]
> Envoyé : mercredi 13 juin 2007 10:36
> À : users@jackrabbit.apache.org
> Objet : RE: Importing and Exporting XML
>
>
>
> Frédéric Esnault wrote:
>>
>> I confirm, the document view is not recommended for two reasons :
>> - some metadata are added during import (at least jcr:primaryType, see
>> spec. 7.3.2.1);
>> - multivalued properties are not exported !
>>
>> Use system view... ;)
>>
>
> When I try this:
> session.exportSystemView(node.getPath(), out, true, false);
>
> ...things get REALLY funky. It starts to look like this:
>
> <sv:property sv:name="jcr:primaryType" sv:type="Name">
> <sv:value>nt:unstructured</sv:value>
> </sv:property>
> .....
>
> And looks nothing like my original document. What am I doing wrong?
>
> Thanks for your comments.
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11095075
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
>
--
View this message in context: http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11095378
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
RE: Importing and Exporting XML
Posted by Frédéric Esnault <fe...@legisway.com>.
Yes the system view is very different from the document view, which is more "business" and/or "human readable". The system view shows your node information in a system point of view, which means in a jackrabbit architecture view.
The information you expect to see (ie node name, property values) are mixed in a huge amount of system information about the node, its type, its mixins, its system properties (mandatory, multivalued....)
It may be quite funky, as you say.
Frédéric Esnault - Ingénieur R&D
-----Message d'origine-----
De : woolly [mailto:p.barr@lbs-ltd.com]
Envoyé : mercredi 13 juin 2007 10:36
À : users@jackrabbit.apache.org
Objet : RE: Importing and Exporting XML
Frédéric Esnault wrote:
>
> I confirm, the document view is not recommended for two reasons :
> - some metadata are added during import (at least jcr:primaryType, see
> spec. 7.3.2.1);
> - multivalued properties are not exported !
>
> Use system view... ;)
>
When I try this:
session.exportSystemView(node.getPath(), out, true, false);
...things get REALLY funky. It starts to look like this:
<sv:property sv:name="jcr:primaryType" sv:type="Name">
<sv:value>nt:unstructured</sv:value>
</sv:property>
.....
And looks nothing like my original document. What am I doing wrong?
Thanks for your comments.
--
View this message in context: http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11095075
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
RE: Importing and Exporting XML
Posted by woolly <p....@lbs-ltd.com>.
Frédéric Esnault wrote:
>
> I confirm, the document view is not recommended for two reasons :
> - some metadata are added during import (at least jcr:primaryType, see
> spec. 7.3.2.1);
> - multivalued properties are not exported !
>
> Use system view... ;)
>
When I try this:
session.exportSystemView(node.getPath(), out, true, false);
...things get REALLY funky. It starts to look like this:
<sv:property sv:name="jcr:primaryType" sv:type="Name">
<sv:value>nt:unstructured</sv:value>
</sv:property>
.....
And looks nothing like my original document. What am I doing wrong?
Thanks for your comments.
--
View this message in context: http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11095075
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
RE: Importing and Exporting XML
Posted by Frédéric Esnault <fe...@legisway.com>.
I confirm, the document view is not recommended for two reasons :
- some metadata are added during import (at least jcr:primaryType, see spec. 7.3.2.1);
- multivalued properties are not exported !
Use system view... ;)
Frédéric Esnault - Ingénieur R&D
Legisway
60 boulevard de la mission Marchand
92400 Courbevoie La Défense
-----Message d'origine-----
De : Shaun Barriball [mailto:sbarriba@yahoo.co.uk]
Envoyé : mardi 12 juin 2007 19:36
À : users@jackrabbit.apache.org
Objet : RE: Importing and Exporting XML
Phil,
When round-tripping JCR data within XML like this I think the recommendation
is to use exportSysView rather than exportDocumentView.
Hope this helps,
Shaun.
-----Original Message-----
From: woolly [mailto:p.barr@lbs-ltd.com]
Sent: 12 June 2007 18:05
To: users@jackrabbit.apache.org
Subject: Importing and Exporting XML
Hi all,
Is it possible to import xml into a node, and then export that xml back out
to have the same xml-equivalent file? At the moment I'm trying:
fis = new FileInputStream(inputFile);
session.importXML(node.getPath(), fis,
ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
fis.close();
// followed by....
out = new FileOutputStream(outputFile);
session.exportDocumentView(node.getPath(), out, true, false);
The difference between inputFile and outputFile seems to be that there are
some additional jcr specific attributes. Is this necessary?
What I'm really trying to do is manage an xml document (eventually many xml
documents), allow people to make changes to only certain parts of it,
versioning those parts and using other JackRabbit features. Is this the kind
of thing that JackRabbit was intended for? Or should I just load the xml
document in as a property of a node and deal with the other things myself?
Thanks for any help,
Phil.
--
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
RE: Importing and Exporting XML
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
Phil,
When round-tripping JCR data within XML like this I think the recommendation
is to use exportSysView rather than exportDocumentView.
Hope this helps,
Shaun.
-----Original Message-----
From: woolly [mailto:p.barr@lbs-ltd.com]
Sent: 12 June 2007 18:05
To: users@jackrabbit.apache.org
Subject: Importing and Exporting XML
Hi all,
Is it possible to import xml into a node, and then export that xml back out
to have the same xml-equivalent file? At the moment I'm trying:
fis = new FileInputStream(inputFile);
session.importXML(node.getPath(), fis,
ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
fis.close();
// followed by....
out = new FileOutputStream(outputFile);
session.exportDocumentView(node.getPath(), out, true, false);
The difference between inputFile and outputFile seems to be that there are
some additional jcr specific attributes. Is this necessary?
What I'm really trying to do is manage an xml document (eventually many xml
documents), allow people to make changes to only certain parts of it,
versioning those parts and using other JackRabbit features. Is this the kind
of thing that JackRabbit was intended for? Or should I just load the xml
document in as a property of a node and deal with the other things myself?
Thanks for any help,
Phil.
--
View this message in context:
http://www.nabble.com/Importing-and-Exporting-XML-tf3908819.html#a11082908
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Importing and Exporting XML
Posted by Alessandro Bologna <al...@gmail.com>.
Wooly,
I agree with what Dan said. Another approach to customize your import
and export that you may find useful can be to use (and extend
accordingly) a couple of classes found in the contrib section of the
Jackrabbit SVN.
http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jcr-ext/src/
main/java/org/apache/jackrabbit/xml
In particular, you may want to look at the DocumentViewExportVisitor
and DocumentViewImportVisitor. You need to understand how SAX parsing
works a bit, but it should be easy enough to customize them to select
what attributes you want to see in your DocumentView export, and how
to map your XML into Jackrabbit nodes and properties.
Incidentally, those classes supports multivalued properties
represented as space separated attributes.
About the SystemView, it is really not meant to be human readable,
more like machine readable (hence the name SystemView), and can be a
bit misleading, because it breaks the node/element mapping that JCR
supports (in the JSR-170 specs is defined as VirtualDocument). In
other words, the xpath expression "/foo/bar" in system view becomes
something like /sv:node[@sv:name='foo']/sv:node[@sv:name='bar']/
sv:value Or something like that...
In my current project, I have implement a REST type interface to the
JCR, so that the XSLT document() element can be used to access JCR
subtrees, and it is very important to preserve the mapping between
xpath in XML fragments (constructed using the
DocumentViewExportVisitor) and the xpath in the JCR, so the
SystemView does not really apply.
Hope it helps.
Alessandro
On Jun 13, 2007, at 6:16 AM, Dan Connelly wrote:
> woolly:
>
> The term "DocumentView" is slightly misleading. Its more like a
> Shredded And Annotated Document View.
>
> The xml document will get shredded into its constituent element
> nodes when you import it as "DocumentView". This import will not
> store a single, coherent document in the Repository. WebDav
> support in Jackrabbit, on the other hand, can be used to store the
> document as coherent text. Customized, hybrid approaches are
> possible to support structured content (partial shredding over
> WebDav). It depends on your use case how much (or how little)
> shredding you want.
>
> The metadata gets added to raw shreds during DocumentView import to
> indicate the Jackrabbit element node type structure. By default,
> node type will be nt:unstructured on raw nodes (not having metadata
> already). You can write a simple XSLT to strip out the metadata
> when you export. For import you can work this in reverse and add
> a custom structure using XSLT (but that may not be simple).
>
> It sounds like your use case (customized node editing) requires
> some custom node types. This can work nicely if the set of
> element tags is limited and fixed. Also, you probably also will
> need to add some custom xml processing (dom, sax or xslt).
>
> What xml editor are you using? I think XML Spy has integration
> features that would support partial shredding and customized
> document views. (But, I have never worked this.)
>
> -- Dan Connelly
>
>
>
>
> woolly wrote:
>> Hi all,
>>
>> Is it possible to import xml into a node, and then export that xml
>> back out
>> to have the same xml-equivalent file? At the moment I'm trying:
>>
>> fis = new FileInputStream(inputFile);
>> session.importXML(node.getPath(), fis,
>> ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
>> fis.close();
>>
>> // followed by....
>> out = new FileOutputStream(outputFile);
>> session.exportDocumentView(node.getPath(), out, true, false);
>>
>> The difference between inputFile and outputFile seems to be that
>> there are
>> some additional jcr specific attributes. Is this necessary?
>>
>> What I'm really trying to do is manage an xml document (eventually
>> many xml
>> documents), allow people to make changes to only certain parts of it,
>> versioning those parts and using other JackRabbit features. Is
>> this the kind
>> of thing that JackRabbit was intended for? Or should I just load
>> the xml
>> document in as a property of a node and deal with the other things
>> myself?
>>
>> Thanks for any help,
>>
>> Phil.
>>
>
Re: Importing and Exporting XML
Posted by Dan Connelly <da...@comcast.net>.
woolly:
The term "DocumentView" is slightly misleading. Its more like a
Shredded And Annotated Document View.
The xml document will get shredded into its constituent element nodes
when you import it as "DocumentView". This import will not store a
single, coherent document in the Repository. WebDav support in
Jackrabbit, on the other hand, can be used to store the document as
coherent text. Customized, hybrid approaches are possible to support
structured content (partial shredding over WebDav). It depends on your
use case how much (or how little) shredding you want.
The metadata gets added to raw shreds during DocumentView import to
indicate the Jackrabbit element node type structure. By default, node
type will be nt:unstructured on raw nodes (not having metadata
already). You can write a simple XSLT to strip out the metadata when
you export. For import you can work this in reverse and add a custom
structure using XSLT (but that may not be simple).
It sounds like your use case (customized node editing) requires some
custom node types. This can work nicely if the set of element tags is
limited and fixed. Also, you probably also will need to add some
custom xml processing (dom, sax or xslt).
What xml editor are you using? I think XML Spy has integration
features that would support partial shredding and customized document
views. (But, I have never worked this.)
-- Dan Connelly
woolly wrote:
> Hi all,
>
> Is it possible to import xml into a node, and then export that xml back out
> to have the same xml-equivalent file? At the moment I'm trying:
>
> fis = new FileInputStream(inputFile);
> session.importXML(node.getPath(), fis,
> ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
> fis.close();
>
> // followed by....
> out = new FileOutputStream(outputFile);
> session.exportDocumentView(node.getPath(), out, true, false);
>
> The difference between inputFile and outputFile seems to be that there are
> some additional jcr specific attributes. Is this necessary?
>
> What I'm really trying to do is manage an xml document (eventually many xml
> documents), allow people to make changes to only certain parts of it,
> versioning those parts and using other JackRabbit features. Is this the kind
> of thing that JackRabbit was intended for? Or should I just load the xml
> document in as a property of a node and deal with the other things myself?
>
> Thanks for any help,
>
> Phil.
>