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? 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 >
