HI Alok.
Alok Aggarwal wrote:
> Hi Jack,
>
> Specifying an empty_str tag which would do fill in
> the defaults differently depending what on the value
> of the tag would fullfill the needs to the AI project.
>
> Do you have a guess on how much time this might take
> to implement?
Implementing what I proposed is easy. It will take a few hours at the
most to code and unit test. (Remember that there is process though,
which can draw things out a bit...)
Thanks,
Jack
>
> Thanks,
> Alok
>
> On Thu, 2 Oct 2008, Jack Schwartz wrote:
>
>> Hi everyone.
>>
>> I've been asked by Alok of the AI team to consider replacing
>> empty-string values in XML nodes with a default.
>>
>> Currently, defaults are added only when nodes are missing from under
>> a parent node; this infers that if a node is present, even if it has
>> an empty string for a value, its value is considered to be present
>> and valid. A parent's child node is either there or it isn't.
>>
>> There are times where one might want to replace an empty-string value
>> with a different one. For example, the AI project may wish to
>> specify something like this:
>> <device></device>
>> in a manifest and have defaults processing fill in the value. This
>> not only documents with a placeholder that a certain element is
>> specifiable in the manifest, but it allows for easy automation of
>> filling in the value. This improves upon having a commented value or
>> comment for a placeholder, because it isn't as easy to uncomment
>> something in automated fashion as it is to just fill in a value.
>>
>> There may also be times where an empty string should be flagged as an
>> error.
>>
>> When assigning defaults to blank valued nodes, what about multiple
>> sibling nodes with the same nodepath? For example, what to do if a
>> parent has two children (which match the same nodepath), and one or
>> both are blank? I propose that all blanks get assigned the same
>> default value. It's easiest to implement this way, and in cases
>> where this doesn't make sense, there shouldn't be multiple blank
>> values in the first place.
>>
>> I propose that:
>>
>> 1) Each "default" entry in the defval manifest have a new optional
>> tag: empty_str. It could be set to
>> "valid", "replace" or "error". If set to "valid", empty strings
>> would be assumed OK as is, and no default assigned to replace them.
>> If "replace", all empty string values would be replaced by a default
>> value. If "error", well, you know the drill...
>>
>> 2) If a parent node has no child nodes matching the nodepath, one new
>> child node with a default value will be provided. (Same as before)
>>
>> 3) If a parent has one or more child nodes which match the nodepath
>> and have an empty string, the value of those nodes would either be
>> skipped, assigned the same default value, or flag an error, depending
>> on the "empty_str" tag assigned to their nodepath in the defval
>> manifest. This would happen regardless of whether the parent has any
>> non-blank child nodes which match the nodepath.
>>
>> I'm not sure that there's time to get this in for November, but I'd
>> like to take your comments on this proposal. Please send your
>> feedback by Monday 10/6 COB.
>>
>> Thanks,
>> Jack
>>
