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 stefan.guggisberg@gmail.com
 designates 209.85.217.12 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=dE9oC+MedVz4H+N4lTDAG8obOwNX3Whx35TKK5cs6O+Z2758VvCOwjc712x0Il/3YG
         Wwq8V7lNb2tF+ekUXXTDBFe99StH7JvJi3UFOTyN7Gxr2/JRj+Q1r0G+C/ykq73Xqm0c
         R5JspK2be05g2W9OcP+rzu8G3gWl0ghCkykMw=
Message-ID: <90a8d1c00811210139r3203edcap940d37e86655e8f2@mail.gmail.com>
Date: Fri, 21 Nov 2008 10:39:26 +0100
From: "Stefan Guggisberg" <stefan.guggisberg@day.com>
Sender: stefan.guggisberg@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: System View XML mapping and multivalued properties
In-Reply-To: <29a095670811200951w2694c164y3c197ac8f0a1ec29@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <FC826B34-E6BB-4667-8127-2573967D447E@gmail.com>
	 <510143ac0811200909q70c15276y827f7aaeef0bac32@mail.gmail.com>
	 <c3ac3bad0811200936x7cca7578q3a3140c88755a46b@mail.gmail.com>
	 <29a095670811200951w2694c164y3c197ac8f0a1ec29@mail.gmail.com>

hi alessandro

On Thu, Nov 20, 2008 at 6:51 PM, Alessandro Bologna
<alessandro.bologna@gmail.com> wrote:
> 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)...

i just checked. there's already a JSR 283 issue (BTW reported by me
in april this year, my memory seems to suffer with age...;) it's been fixed
in the current (non-public) draft. however, there's a minor problem, the
newly introducedl attribute is not in the 'sv' namespace, as you correctly
proposed. i'll create a new issue to address this.

cheers
stefan

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