I am assuming that you mean this example in the specification:
9.1.4 Example - Using 'propname' to Retrieve All Property Names
The example shows that the correct response to a PROPFIND request on
<propname/> is a list of all names of supported properties. The names have to
be provided as XML elements, what is rather weird as the typical XML user
expects to include them as a simple blank separated values list instead of an
The problem is that the same specification mandates that each property must
contain a particular, valid value, e. g. <creationdate> must surround a real
date value. It makes sense to prevent creation if "empty" elements, since those
are most typically created by fault instead of by intention.
So the title of the bug report is misleading. It is absolutely correct by
intention, that the default constructors are private, as this prevents errors.
The actual problem is that there shall be support for valid <propname/>
request's <prop> response. Due to this, I am replacing the title of this bug
The question is, how it shall be possible to create empty property elements to
fulfil the need to just list them up, while still be able to keep backwards
compatibility and keep the existing safety to prevent unwanted empty elements.
A proposal could be to actually make the default constructors public as you
said, while still keeping the null check in the with-value-constructor
("builder constructor"). This would serve both purposes but still keep at most
safety: You can omit the value, but if you provide one, it must not be null.
The JavaDoc of the default constructor then should contain a note that it must
only be used in exactly that sole case, while in all other cases the builder
constructor (including a valid value) has to be used.
Would this solution look like what you like to get? Do you see a different