um, this is tricky.  I'll need to check the code, but I believe that the
extended attribute list is actually only available in the sharedresource, and
the short list is what is actually advertised by Button as attributes of a widget.

Changed target to 1.99 RC 1.

LABEL should now be found, this was fixed as part of bug 782 :)  The remaining
attributes are still not registered ...

Since they are only available in the sharedresource and not as part of the
widget, the question is:

1. should this bug be marked fixed and the task is a documentation one?

2. should the attributes be added such that they could be included in the widget
tag.  Personally I think they should NOT be added.

I thought I had a clear understanding of what a shared resource is and what it
represents.

Description of SharedResource from help viewer:
 
SharedResource is an invisible widget that defines some set of values that are
to be shared among one or more widgets. Shared Resources are used as a global
placeholders for sets of common attributes from a widget or an attribute group.
The attributes allowed in Shared Resources, and their individual
formats/structures, are defined within the code for the individual widget or
attribute group. Shared Resources help Chameleon application developers better
manage all their different attribute sets. 

pauls comment#3 brakes this fundamental concept/rule. If attributes that are
defined in the shared resource can only be declared in a shared resource and not
within the widget. Than this is an issue, that needs to be discussed further.

--------
Despite this issue. In my opinion, ALL attributes should be
declared/registered/found during the doc building process, where ever they are
declared within chameleon.

And once found should be dumped into the corresponding widget document (widget
or attribute group) that the attribute was found in.

Paul stated that there where two direction this issue could be dealt with. I
would argue that this is both a documentation issue and development issue rather
than one or the other.

From the documentation point of view:

1) all attribute should be found during doc_builder process.
2) Since, there are attributes declared within a widget that are shared resource
specific (ie. can only be declared in the template under the shared resource)
there should be a new Attribute Class eg. Shear Resource Only. Currently there
is only three attribute class. 

They are: 
1) Require, 
2) Widget Only, 
3) Widget & Shared Resources

I think the bigger question is: 

* Is it ok to create a new Attribute Class "Shear Resource Only"?

I am not a big fan of having attributes declared in the widget that can only be
used in the shear resource. This new class will have to be created for
documentation, if this is not addressed within code.

The description of the SharedResource is not entirely accurate I guess.  Take,
for instance, the projection shared resource.  The elements of that
SharedResource cannot be used as part of the Projection or ProjectionLabel
widget, nor would it make sense to.  The issue here is that you want to make
everything behave consistently regardless of whether there is a good reason to
do so or not.  In this case, there is absolutely no technical benefit to making
these attributes available as part of a widget tag.  They would not be useful
and would, in fact, only cause confusion on the part of the user.  

It was my understanding that there was a place in the documentation structure to
document the contents of SharedResources associated with widgets.  This is the
place that the buttonizer SharedResource should be documented, if anywhere.

I am against adding more and more attributes just for the sake of making it
appear more consistent, when in fact I would never condone the use of the
attributes as part of the widget.

Also note that the documentation builder is limited in what it can automatically
discover about the widgets.  SharedResource structure and contents is not
currently coded in such a way as to expose it to the documentation building
process.  By way of example, every attribute that a widget can accept in the
cwc2 tag is 'registered' with the widget so that the widget code can
automatically verify the attribute and its content.  There is no registration of
SharedResource contents.  SharedResources are simply a placeholder for some
unstructured information.  Widgets can choose to interpret this in any
convenient way.  The use of XML within a SharedResource in the template is a
convention that is useful, but not necessary.  

What is, perhaps, missing is a mechanism for the widgets to declare the contents
of SharedResources in a way that can be validated (as widget attributes are
declared and validated).  I would see this as a useful change as it would allow:

1. more complete automated verification of templates
2. support for automatically documenting SharedResource structure associated
with widgets.

This would require a moderate amount of new development and should be considered
a new feature, which likely means that it should not be entertained for 1.99/2.0
at this point.  However, if we are going to do it, then it should be done for
beta 3.

Well, from my point of view, it is obvious that we need to revisit exactly how 
Shared Resources (and their attributes) interact with the widgets (and their 
attributes) with which they are associated. Given that it seems there are 
several different ways this interaction is handled, I think that we need to 
take a very close look at it for *all* of Chameleon. I'm all for consistency, 
but not without thorough analysis first and not at the price of "reason". (I'm 
also not for letting "reason" just block consistency. I'm a centrist and 
believe that, in most cases, both can be served with proper design.)

Anyway, given all this, I am suggesting that this issue gets dealt with post-
2.0. Thinking we can do a good job of it in the beta-3 rush is unrealistic. 

As for Chris's question - yes, I think it is OK (until we get this whole thing 
ironed out post-2.0) to create a new Attribute Class called "Shared Resource 
Only". I say we alter the widget-doc process and templates to reflect a "blank" 
tag for this class and, since there's no way to capture this information 
automatically at this point, manually make note of any occurences of this class 
in the base widgets. 

Changed target to FUTURE.

I agree with this paul, this is what I am looking for and should be consider for
the future as Darren suggests (which I also agree with).
-----------------
What is, perhaps, missing is a mechanism for the widgets to declare the contents
of SharedResources in a way that can be validated (as widget attributes are
declared and validated).  I would see this as a useful change as it would allow:

1. more complete automated verification of templates
2. support for automatically documenting SharedResource structure associated
with widgets.
----------------

As for your comment paul about your expectations of what the widget docs have of
the shared resource section. yes there is a sheared resource section, but if you
view for example the Button attribute group you will notice that the Shared
resource section is meant to describe how this user can utilized the shared
resource for that particular widget/attribute group. It also contains examples.
In this section it does not make sense to outline shared resource attributes. 

Personally All attributes related to the widget/attribute group weather they are
used in the widget or strictly in the shared resource should be explained in the
shared resource section.  

Once we have a clear/consistent way a sheared resources is used and/or defined
we can deal with how to document this chameleon feature.

One last comment, in the past I was under the impression that the these Shear
Resources Only attributes could be defined in the widget and a one or two of
these attributes were defined that these attributes would take priority over the
same attributes defined in the Shared Resource. I never tried doing this with
the Text button shared resources, but this was what I thought.

I created a new bug to address the changes that will currently have to de done
on the widget doc xml schema (bug 808)