Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of mwaschkowski@gmail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=DSuXKJVhThSufKkbjCHUUuV4eX3NqXjvtuFElc/2CXD3HCr9jYXvdJqkTCBQ7Ibp4gUCj8d8UGB1dKKEA01wWAcMyqglgWRfyriQgUCAlCRH5ImwFlzNvTsX0L68CvNAFz5VtDiHmk+X+WTctcm5WQoKXmI0Wk7l1fECY2OWdYw=
Message-ID: <76a6ebd00707191426l493ced42w7d3e3e705394ab76@mail.gmail.com>
Date: Thu, 19 Jul 2007 17:26:36 -0400
From: "Mark Waschkowski" <mwaschkowski@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: 3.1.3.1 Removing Items
In-Reply-To: <469FB38A.9000508@yourmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_79913_3948320.1184880396060"
References: <469F7E7C.4090906@yourmail.com> <469F8399.5020404@gmx.de>
	 <469FB38A.9000508@yourmail.com>

------=_Part_79913_3948320.1184880396060
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

"That's true, but the JCR behavior seems harmless to me" re:setting null
causes property to be removed
Actually, this caused a problem for me. I needed to represent a node in xml,
and so created a transformation from a node to xml, but noticed early on
that if a property was set to null, my xml representation showed nothing at
all (no property name or value). This isn't acceptable when trying to output
the state of something to the end user. So instead I had to create an object
from the node and then create xml output for the object instead of just
transforming the node to xml. It appears to me to be an unnecessary step
forced on me due the the api. I don't understand why setting the property
value to null would also remove the property rather than just setting the
value to null.

"I strongly disagree. Being absent, and having an empty string value are
completely different things. Font instance, you can't have a "null"
attribute value in XML."
Well, I agree that having an empty string value and being absent (and having
a null value) are all completely different things. However, I do see removal
of the property itself as a side effect of setting the property to null.

Yes, 'null' doesn't really apply to attribute values, but:
1) Attributes can be empty ie. id=""
2) there IS a difference between an empty attribute and an attribute that
doesn't exist! See:

http://mail-archives.apache.org/mod_mbox/xerces-c-dev/200105.mbox/%3COF0B70FE7F.05B157D7-ON85256A54.00736CAA@torolab.ibm.com%3E

IMHO most people will, on first time use, expect that properties set to null
are still part of the node, just empty or nullified, and I don't see the
justification for having this unintuitive 'side effect' when setting the
property to null. But I certainly have an open mind about there is some
underlying reason for this behavior!

"I totally agree that teaching people to use p.remove() would be
preferable."
Me too. Making it mandatory even better :-)

"I personally think that 2.0 *should* be as compatible as possible (and
yes, that means that people should be ably to rely on XPath)."
That would be great - I find it very surprising that it was deprecated and
if the committee would really like to see the standard flourish, that it be,
um, un-deprecated.

Best,

Mark


On 7/19/07, IvanLatysh <ivan@yourmail.com> wrote:
>
> Julian Reschke wrote:
>
> > I strongly disagree. Being absent, and having an empty string value are
> > completely different things. Font instance, you can't have a "null"
> > attribute value in XML.
> XML attribute isn't type strict as JCR is.
> So parameter.setValue(valueFactory.createValue((Double)null)) should
> result a
> parameter of type 'Double' with null value.
>
> >>   Deleting the property or node and setting the value is a two
> >> different use-cases.
> >
> > That's true, but the JCR behavior seems harmless to me. The only
> > alternative that would make sense would be to reject (by throwing an
> > exception) those requests,
> No, it is not the only alternative, but to handle it properly is a better
> way.
>
> >>   Also JCR API is not consistent in this matter, when consistency is
> >> most important part of any spec.
> >>
> >>   Here is inconsistence that I refer to:
> >>   1) to delete the Node we call: myNode.remove();
> >>   2) to delete the Property we call: p.setValue((Value)null);
> >>
> >>   In the second case I expect to see: p.remove();
> >
> > You can do that as well, can't you?
> Yes I can do that. And as I sad: API is not consistent.
> Spec promote usage of "p.setValue((Value)null)" as the way to remove the
> property when it should say to use " p.remove();" instead.
>
> >>   === Proposal ===========================================
> >>
> >>   * Setting property to NULL will set property value to NULL without
> >> any side effects, such as removing a property.
> >
> > That would be a major change in the data model. No way.
> I believe it is a community process so committee will discuss it.
> And again it is funny to hear that it is a major change when XPath just
> has been
> dropped.
> Be reasonable, if you brake the spec, at least fix the obvious bugs.
> Anyway 2.0 won't be compatible with 1.0
>
> --
> Ivan Latysh
> ivan@yourmail.com
>


-- 
Best,

Mark Waschkowski

------=_Part_79913_3948320.1184880396060--