|
From: Karl W. <ka...@wa...> - 2005-01-11 01:03:31
|
Trying to get the empty string vs. null discussion restarted.
Karl Waclawek wrote:
>
> I had another look at the Java API.
> It seems it is quite inconsistent with respect to empty string vs. null.
>
> Examples:
>
> - In EntityResolver, all occurrences of publicId or baseUri
> are supposed to be null, when absent.
>
> - DTDHandler.notationDecl(): publicId, systemId can be null,
> if not provided
>
> - DTDHandler.unparsedEntityDecl: publicId can be null if not provided
>
> - DeclHandler.attributeDecl(): mode and value can be null, where
> in the latter there is actually a semantic difference between
> value = null (meaning: none defined) and value = empty string
> (meaning: a value is specified, and it is the empty string).
>
> - DeclHandler.externalEntityDecl: publicId can be null, if not provided
>
> - LexicalHandler.startDTD(): publicId, systemId can be null,
> if not declared
>
> It actually seems that the prevalent approach is to use null for absence
> of a string parameter, and only in the case of namespaces does the API
> stray from this rule.
>
> However, I would strongly suggest that we remain consistent in
> SAX for .NET. If we pick String.Empty, then we need to allow one
> inconsistency - and that is for the Value parameter passed to the
> attributeDecl() call-back.
Originally, this thread was about namespace URI references
and prefixes. The question was whether they should be passed
as empty strings or as null references when absent/not applicable.
However, whatever the outcome of this discussion, it should be applicable
to the whole API, but not as a general rule of either always null
or always empty. The reason is that in the case of DeclHandler.AttributeDecl(),
the "value" parameter has well defined meanings for both, empty string
and null, so both must be allowed depending on the intended semantics.
Maybe we should first ask, when such a problem of deciding
between an empty string or null actually exists?
I would say that is the case when the meaning of both
is "roughly" the same: an undefined or absent string value.
Two examples where I would intuitively make different decisions:
1) ParseError.Message, or SAXParseException.Message:
In this case I would always assume that there is a message,
even if it is an empty string. It looks wrong to me to
even allow a null value.
2) Locator.PublicId: If there is no public identifier, then
one should make its absence clear. null is better at that.
One could think of this as a guideline:
- If we would say: this string parameter/argument/value
can be absent, then let's use null to indicate it.
- If we would rather say: this string parameter/argument/value
can be empty, then let's use "" to indicate it.
Coming back to the SAX API:
How would the above guideline be resolved for namespace URIs
and prefixes when an XML name is not in any namespace?
Karl
|
