[jdom-interest] questions about org.jdom.ProcessingInstruction

[Brett McLaughlin]

Ed Morehouse wrote:
> 
> I've been looking at org.jdom.ProcessingInstruction and have a few questions:
> 
> - The "data" portion of a ProcessingInstruction seems to be stored as both a
> String and a Map; is this, in fact, the case?

Yup.

> - If so, what is the rationale for this, as opposed to just using one or the
> other?

Honestly, I don't remember ;-) Most likely because in some cases, one
works /really/ well, and in others, the other does.

> - Would a Map alone suffice to store all the possible "data payloads" a
> processing instruction could legally have?

Not really. Remember that a PI does not have to be in attribute-value
format. This is perfectly legal:

<?target someValue?>

Here, there is no "key" for the map. But it would be fairly simple to
write the map in a way where some NO_NAME type key was set up, and the
value inserted. Of course, you could have multiple values with no name,
and you need different keys, but storage in a Map completely, (or in
String completely) is simple.

> - If so, it seems to me that the Map would be more powerful (and more OO), and
> would relieve the application programer from having to do a good deal of String
> processing.  Does this seem right?  Am i missing something?

Maybe just the odd PI case above.

> - There is a constructor that takes a Map and an internal Map already, but there
> doesn't seem to be any way to get a Map back out from a ProcessingInstruction;
> is this so?

It is so, because of the special case. It's one thing to store these
values internally with some sort of special NO_NAME key or whatever -
but giving that back to the developer I am against. That's why we let
them look up by attribute name, or get the whole thing raw, but not give
back the Map itself - if we store things completely in a Map, that Map
will sometimes have weird keys.

> - If yes, what would be the implications of adding a public Map getDataMap()
> method to ProcessingInstruction?  If there weren't also a shadow data String,
> manipulating the Map directly seems like it would be okay and wouldn't cause
> corruption.  This seems like it would fit in with the philosophy of using Java's
> native Collection interfaces to simplify XML programming, as in the case of the
> live child List in Element.  Does this sound right?

See above.

Hope this starts us down improving the PI class - it's been dormant for
a long time.

-Brett

> 
> I'd appreciate feedback and comments, especially from Jason and Brett, but also
> from anyone with insight into this topic.
> 
> Thanks,
> 
> - Ed
> 
>                                   ------------
> 
>  - The happiest of people aren't the ones
>    who always have the best of everything;
>    they are the ones who always make the best
>    of everything they have.
> 
>                                            Ed Morehouse
>                                            Software Engineer/Evil Genius
>                                            The Motley Fool
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org