Thanks Jukka, I guess i have been a bit lazy not looking at the jira first ;)
Alex, yes, JSR-283 does not seem to address the issue at all (just like 170). Maybe, if there's somebody who happens to read this thread and is in the committe, that person could propose to address it (hint hint)... In the end, System View is the only way to guarantee data migration/interoperability between different JCR implementations and it's not a minor issue when the the contents are ambiguously serialized (and we all dislike silos...) In the meanwhile, with our JCR (JR of course) I think that the solution presented by Stefan (using a rep: attribute on the sv:property, if I understand him correclty) may be the way to go (just in case somebody is validating the SV schema strictly, to add an attribute in a different namespace may be less intrusive). It seems to be a minor change in the code. Then once JR becomes 2.0 compliant, we could use sv:multivalued="true" or something like that. Thanks. Alessandro On Thu, Nov 20, 2008 at 12:36 PM, Alexander Klimetschek <[EMAIL PROTECTED]>wrote: > I looked at the JCR 2.0 spec public review and it does not fix the > issue. Do we have a chance to include such a sv:multivalued="true" > marker for the 2.0 final? > > Regards, > Alex > > On Thu, Nov 20, 2008 at 6:09 PM, Jukka Zitting <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > On Thu, Nov 20, 2008 at 5:29 PM, Alessandro Bologna > > <[EMAIL PROTECTED]> wrote: > >> Maybe I am missing something, but if that's the case that I am not, > maybe it > >> would be worth adding some implementation specific workaround, such as > >> adding an optional sv:multivalued="true" attribute that then can be used > >> transparently during import. It should not break anything I believe > (unless > >> there's some strict validation of the SV schema in place). > > > > You're right, the spec is incomplete in that case and the only thing > > we could do for now is to add some implementation-specific multivalue > > marker. See also https://issues.apache.org/jira/browse/JCR-1464. > > > > BR, > > > > Jukka Zitting > > > > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
