OK, I read it all, but I'm not sure I understand everything. How would specific docklets that use specific variables be tied in that? Or would it not be? For example, a widget that remembers its position on the screen. We would still use the registry for those specific purposes?

Will,

Thanks some good thoughts there. Text color is a good one, I'll add that.

As for the hemisphere there is no need (assuming weather.com is used) as you can just use the latitude parameter for this. As for the other units I think I'll hold off on that for now. Given that the Metric/Imperial option caters for the majority of these I'd argue that if you want to add options for these that is the sort of thing to be performed as a separate calculation. If necessary this could be stored in the AOI though I would have concerns if people started overwriting defaults with their own custom choices. Of all the weather objects I've made, I can't say I've had anyone asking me if I could put windspeed in knots.

Corky_O,

Thanks very much - I appreciate this.

paxx,

The Additional Object Information will handle this. There will not be much to this section beyond identifying the widget, it's author and the various parameters that are to be stored. The sole goal of this is to enforce a structure that controls the way this data is held rather than it being scattered across the registry, ini files, persiststorage etc.

This one file will be far more transferable that the current options.

This is very good.

I got some proposal.
*
Change ver="0.1" to version="0.1" and to as it makes for easier reading. With too many shortened words it may end up confusing as the list of settings will grow.

*
Have version control for the sub categories as well. i.e. . I was thinking if only a sub-section where to be changed it would create less incompatibillity issues if only the version number for the subsection is increased as oppose to the entire setting file.
My thinking is mode modulebased.

*
As I said earlier I was working on a XML parser that would build a DOM tree. I had plans for a function that would let you access the info in the XML DOM tree in a path sort of way. i.e.: getSetting("dxinfo\information\weather") something that would return an array with the info contained under the weather section. Or getSetting("dxinfo\information\weather\units") to get the data for one spesific setting.
I propose the "dxinfo" part of the path to be optional as dxinfo is the root of the document.
getSetting might take an extra optional argument to return the array as either a VBS array or JScript array.

*
Some sort of forum to manage, propse and discuiss the standards.

A little semantic addition.
for the section:
I belive is a better choice of word than and instead of
Working out some good names that lead to less confusion and describe the content is something that I think will be important to make this rock solid.

Thanks for these suggestions - this is all good stuff.

ver is version in 0.2

Not sure about versions for subcategories on the basis that once we hit 1.0 I really don't expect the structure to change.

Check out the samples in 0.2 and you'll see that data is extracted in just this way.

I want to ensure that nothing is optional as this will dilute the standard.

I agree on terminology - this is what we need concensus on.