[jdom-interest] Processing instruction map issues

[Bradley S. Huffman]

Elliotte Rusty Harold writes:

> The original data has been completely overridden with no warning by the 
> pseudo-attributes. I'm not sure what to do here. There are a couple of 
> possible solutions:
> 
> 1. setValue() should throw an exception if the Map is null; i.e. if the 
> PI was not initially set up with a pseudo-attribute format.
> 
> 2. The pseudo-atts should just be appended to the data; i.e.:
> 
> <?target some random non-attribute-like data name="value" name2="value2"?>

> I think I prefer option 1, but I'm not sure. Whatever we choose, eve 
> sticking with the current behavior, the behavior should be documented in 
> the JavaDoc

3. Get rid of all the Map stuff and let each the application parse the data.

4. Get rid of setValue, getValue, and removeValue. And since name/value pair
   arguments are probably a common case have a setData(Map) and
   Map getDataMap() as a convenience, in addition to setData(String) and
   String.getData(). For mixed attribute-like/non-attribute-like data
   you'll have to use the String versions and parse it yourself, but I
   don't see this as a common occurance. Internally I go so far as just
   to store the data as only a String, and let setData(Map), getDataMap()
   convert on each call.

> Issue 2:
> 
> The name setValue() is misleading. It sounds like it sets the entire 
> value of the PI. 

Agreed.

> What it really does is add a pseudo-attribute. The 
> following names all strike me as more accurate:
> 
> addValue()
> addPseudoAttribute()
> setPseudoAttribute()
> 
> I think I prefer addPseudoAttribute()

addArgument()? But I think I like #4 better, simplifies the API a little.

Brad