Operations » Editor » Public Comments » Public Comments Archive

XPath 2.0 has a fn:nilled function for testing if something is nil.

If we added that to the set of functions DFDL provides, plus a constructor, suggest dfdl:nil().

The only additional thing would be to define how expressions that encounter nil behave.

Having the constructor dfdl:nil() may cause issues.

Consider this expression

if ($p = 5) then "a string" else dfdl:nil()

Since XPath/XML doesn't really have a notion of nil (it's really an empty XML element with a special attribute xsi:nil='true'), there is no way to carry around a nil value as part of a calculation. Another way to say this is that XPath/XML allows nilled elements. But does not allow nil values.

So if we want DFDL implementations to be able to reuse an XPath implementation as a means of implementing DFDL expressions, then this dfdl:nil() constructor idea would be rather problematic.

I suggest we eliminate the value 'nil' from the DFDL Infoset, and add a member [isNil] (or we can copy whatever name XDM uses for this) which is a boolean for nillable elements, and has no value otherwise.

Then we can add the fn:nilled function to test this boolean.

XDM calls this infoset member 'nilled'.

• remove all discussion of nil as a special value
• add [nilled] member to element information item
• add fn:nilled function to expression language

There's a section in the XPath 2.0 spec that is worth a read - 2.5.2 Typed Value and String Value. The typed value takes into account the nilled flag, and is the empty sequence if nilled is true. Given our infoset only deals with typed values, then this implies that an attempt to get the value of a nilled element should return empty sequence. We should state this somewhere in section 23.

Combining prior two comments. Add the language about taking the value of a nilled element to section 23.

New errata 4.3 in experience document 1.

DONE in draft-gwdrp-dfdl-v1.0.4-r05.docx. Note that I searched the entire spec for all references of nil, and there were additional sections where wording had to be revised so as to describe nil properly based on the [nilled] member versus a distinguished Nil value.

http://redmine.ogf.org/issues/175