"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/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
-- Best, Mark Waschkowski
