Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of alessandro.bologna@gmail.com
 designates 209.85.198.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=mJ3JlG9lJphCYvfjRHhkGS7sBOHH279d9PvlpaGvVVBYQtgVo/rHdDrdb0FLGBZ6LX
         e9gB4CfPjLQTWdcIZ2t3v6s5h7QideaQodAs1PwSkwbUI3m9NvYk9N3fRWTkS1THQXyz
         jDGXudl6e1F4/+hISuKzw2mO59QgBGyY9GAwM=
Message-ID: <29a095670811200951w2694c164y3c197ac8f0a1ec29@mail.gmail.com>
Date: Thu, 20 Nov 2008 12:51:55 -0500
From: "Alessandro Bologna" <alessandro.bologna@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: System View XML mapping and multivalued properties
In-Reply-To: <c3ac3bad0811200936x7cca7578q3a3140c88755a46b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_96310_12129574.1227203515992"
References: <FC826B34-E6BB-4667-8127-2573967D447E@gmail.com>
	 <510143ac0811200909q70c15276y827f7aaeef0bac32@mail.gmail.com>
	 <c3ac3bad0811200936x7cca7578q3a3140c88755a46b@mail.gmail.com>

------=_Part_96310_12129574.1227203515992
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <aklimets@day.com>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 <jukka.zitting@gmail.com>
> wrote:
> > Hi,
> >
> > On Thu, Nov 20, 2008 at 5:29 PM, Alessandro Bologna
> > <alessandro.bologna@gmail.com> 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
> alexander.klimetschek@day.com
>

------=_Part_96310_12129574.1227203515992--