jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: xml import/export in simple webdav server
Date Thu, 09 Jun 2005 00:26:40 GMT

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!
>>
> 
> 
> 


Mime
View raw message