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 julian.reschke@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <46A06B7E.6040703@gmx.de>
Date: Fri, 20 Jul 2007 09:59:58 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: 3.1.3.1 Removing Items
References: <469F7E7C.4090906@yourmail.com>
 <469F8399.5020404@gmx.de>	 <469FB38A.9000508@yourmail.com>
 <76a6ebd00707191426l493ced42w7d3e3e705394ab76@mail.gmail.com>
In-Reply-To: <76a6ebd00707191426l493ced42w7d3e3e705394ab76@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Waschkowski wrote:
> "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 

Well, that's a very absolute statement. I think it's a very natural way 
to output a state.

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

Because the property model doesn't allow a value of "null". So yes, the 
API might be clearer if trying to set a value to null would throw an 
exception.

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

No, it's the only effect.

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

Yes. JCR properties can have the empty string as value as well or be not 
there. That's exactly the same as for XML attributes.

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

I looked at this but couldn't find how this is relevant. Maybe you could 
add a few sentences of explanation.

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

Again, the underlying reason is the data model for properties. And I can 
only guess that that wasn't chosen arbitrarily, but with compatibility 
with other property models in mind.

> ...

Best regards, Julian