On 7/6/05, Tobias Strasser <[EMAIL PROTECTED]> wrote: > > Angela Schreiber wrote: > > > since the new commons with the main-jackrabbit source > > > now causes problems, i would like to have that > > > interface defining some constants being available > > > in the jackrabbit-commons, so i could remove the > > > commons in jcr-server. > > > > +1, as explained in the message forwarded by Angela. > > > > Additionally, I'd like to refactor the internal Jackrabbit nodetype > > object model and the nodetype XML format code into jackrabbit-commons. > > I've already done this work for the contrib/jcr-ext package to be used > > for my JCR adapter projects, but having a shared codebase with > > Jackrabbit would be _so_ much better. > > that would be cool. > > additionally, i thought of a more jcr-like way for an xml format of > the nodetypes. why not using the docview serialization of the > respective nt:nodeType nodes that represent the nodetype? the > advantage would be, that the format and structure are already > indirectly defined within jcr, export and import are also available in > jackrabbit.
using docview serialization sounds like a good idea. however docview is not guaranteed to safely roundtrip. e.g. there's the problem with multi-valued properties. according to the spec it's up to the implementation how it should handle those on export/import. also, i'd rather not stretch the already very complicated semantics of Session/Workspace.importXML with new features like 'auto-register node types'. node type management should IMO be the sole responsability of a dedicated NodeTypeRegistry. cheers stefan > > cheers, tobi > -- > ------------------------------------------< [EMAIL PROTECTED] >--- > 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 >--- >
