Hi Shawn, > XML works best for structured data that > involves a given set of paramters, with a maximum value on > persistence across entities, and minimal reliance on interface.
Sorry, I just don't understand what you're saying... Can you re-phrase that? > What happens with "&", ">" and ">" as aliases > or within the bodies of values of alias fragments? They get > screwed up or involve significant hand-holding to make them > work. Good point... It seems only ">" is valid as contents of an attribute. On the other hand, if we're to build a UI for configuration, proper encoding takes care of itself. Sure, hand-tweaking is harder until you learn that "&" is "&", ">" is ">" and "<" is "<". That's it. > For the prefs it's even worse. The prefs really are straight > javascript and can't easily be moved into a logical XML > structure without losing the benefits of the fact that they > are script-based. I actually want to get rid of the fact that it is script. Most of the uses can be expressed equally simple in a markup language, and the rest, well, they probably shouldn't be there, IMO. I haven't seen a single piece of active script in preferences.js, most of it is just var declarations. > I can see that it would be *possible* to generate the script > dynamically from XML values, but we lose situations where we > want to prioritize the order of values being set or very > tight control over the text used in the script (without using > CDATA blocks which make things even weirder). Why do you feel the pressing need to have preferences.js contain script code, rather than declarative settings? Cheers, Kim ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
