jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Strasser <tobias.stras...@gmail.com>
Subject Re: xml import/export in simple webdav server
Date Thu, 09 Jun 2005 06:26:05 GMT
hi brian,
there where a lot of changes in the jcr-server project, and i should
have written a few notes to it. sorry for this. the biggest part,
was the proper separation between the subproject. one goal was to
make jcr-server/server and jcr-server/webdav completely jackrabbit 
independant. secondly, the inport chain commands had some flaws...
there was too much magic involved of how the commands work. i'm still not
very happy with this solution. i think the chains offer a great
flexibility, but there must also be known alot about how the 
commands work. i will look into the XML problem again, and increase
the version number. probably, it should be independant of jackrabbit's.

cheers, tobi


On 6/9/05, Brian Moseley <bcm@osafoundation.org> wrote:
> 
> it looks like XMLImportCommand has changed to take the first problem
> below into account. were any of the the other issues addressed?
> 
> i just tried to use the command to import an xml file and, although the
> webdav request succeeded, the resource was shown in cadaver as having
> length 0, and cat-ing the file indicated empty content.
> 
> Tobias Strasser wrote:
> > hi brian,
> > you are completely correct, the xml roundtripping does not work
> > properly yet. there are the some problems, 2 of them you mentioned:
> > 1) jcr:content is exported, instead of the first child node of it.
> >    imo, this is a little flaw in the symmetry of Session.import/export.
> >    the primary item does not work here, since it cannot be set dynamically.
> >    the workaround will be to start with:  content.getNodes().next();
> > 2) the jcr properties that were added during import should be filtered out
> >    during export.
> >
> > but there are more issues:
> > 3) DTD information of the imported XML is lost
> > 4) formatting of the original XML is lost, which could be nasty when
> >    editing a XML file in a text editor on a webdav-mounted share.
> > 5) comments are lost
> > 6) other processing instructions are lost
> > 7) sequence of attributes is lost
> > 8) CDATA information is lost (the existence that text was cdata)
> > 9) encoding of XML document should be preserved
> >
> > those issues render the default docview import/export of jsr170 useless
> > for this kind of application. we are about to define a more reliable
> > format for xml-roundtripping, primarily be specifying a set of node types
> > that map the xml-dom. we probably cannot make use of the existing
> > docview import/export, but must write an own handler for this purpose.
> > this is no problem, since the webdav server dictates the way how the
> > content should be stored.
> >
> > cheers, tobi
> >
> > btw: Day's CRX includes a nice tool for browsing a jcr repository.
> >      take a look at the 'content explorer' in http://jsr170tools.day.com/
> >
> >
> >
> > On Apr 11, 2005 10:49 PM, Brian Moseley <bcm@maz.org> wrote:
> >
> >>so far i'm using FileImportCommand and FileExportCommand to read and
> >>write my xml files. all is well. now i'd like to move to importing and
> >>exporting them because, as was pointed out earlier, it would be nice to
> >>have the xml data stored as nodes for searching purposes.
> >>
> >>in XMLImportCommand, a jcr:content node is created and the resource is
> >>imported beneath that. however, in XMLExportCommand the jcr:content node
> >>itself is exported. this causes the generated xml to be wrapped in a
> >>jcr:content element, like so:
> >>
> >>   <jcr:content jcr:primaryType="nt:unstructured"
> >>jcr:mimeType="text/xml" jcr:lastModified="2005-04-11T13:44:42.995-07:00">
> >>     <Share jcr:primaryType="nt:unstructured"
> >>kind="//parcels/osaf/framework/sharing/Share"
> >>uuid="87b574ee-aaca-11d9-d6f9-000d935d33e8">
> >>       ...
> >>     </Share>
> >>   </jcr:content>
> >>
> >>i tried adding code in XMLExportCommand to get the primary child of the
> >>jcr:content node and export that, but i got an ItemNotFoundException,
> >>leading me to believe there isn't actually a child node beneath the
> >>jcr:content node. if that's the case, then what exactly does the import
> >>do? reviewing the spec, it looked to me like the import should have
> >>actually created nodes beneath the jcr:content, but maybe i
> >>misunderstood. if new nodes aren't created, then how does one search on
> >>the imported content?
> >>
> >>so the big money question is: how do i change/extend XMLExportCommand so
> >>that it exports xml without the wrapping jcr:content?
> >>
> >>also, is there any easy way for me to cause the jcr attributes to not be
> >>included in the exported xml? the jcr spec indicates that i could
> >>provide my own sax handler, but i'd rather not do that :) i'm pretty
> >>sure that most/all webdav clients will be smart enough to ignore the jcr
> >>attributes when they're parsing the xml, but if i can filter them out
> >>before serving my response, that would be preferable.
> >>
> >>thanks!
> >>
> >
> >
> >
> 
> 


-- 
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Mime
View raw message