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 <[EMAIL PROTECTED]> 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!
