Update to controlled values proposal

Hi, Esteemed TC:

I've updated the controlled values proposal:

http://www.oasis-open.org/apps/org/workgroup/dita/download.php/26358/IssueControlledValues12031.dita

And the equivalent web-browseable output for convenience:

http://www.oasis-open.org/apps/org/workgroup/dita/download.php/26359/IssueControlledValues12031.html

Changes in this version:

*  Added an <elementdef> so different enumerations can be specified for the same attribute on different elements (per discussion last Tuesday).

*  Renamed <propertydef> to <attributedef> for consistency with <elementdef>.

*  Added <defaultSubject> after <attributedef> to specify a default value as part of a binding -- I believe Deborah raised that issue.

*  Switched from using a known catalog identifier for the subject scheme to an explicit reference to the subject scheme in the content map (per Eliot's comment and for consistency with the keys proposal).

*  Added the <subjectHead> element to label groups of subjects

*  Cleaned up the content models to be consistent

Following up on an earlier note from Eliot exploring whether some TopicMaps issues applied to subjects, the keyref discussions have established keys as globally unique identifiers.  Thus, there is no need to deal with disambiguation issues for keys, and references to subjects can never be ambiguous.  

The issue about flagging <topicref> specializations that should not contribute to output (perhaps with an attribute that is more general than toc="no" print="no") remains an active general issue with specific bearing on <topicsubject> and <topicapply>. 

Stating the obvious, the keyref proposal must be approved before this dependent proposal can be scheduled for a vote. 

Separate from the controlled values proposal is the question Deborah raised about whether to apply the proposal to some existing base attribute enumertions such as note@type and topicref@collection-type.  Perhaps tool vendors could speak to the issue of whether that change could be contained easily or whether it would be better to switch such core enumerations to controlled values in a future release. 

Similarly, if the controlled values proposal is approved, the learning subcommittee may want to consider taking advantage of the controlled values capability for their attribute enumerations to provide default enumerations that are easy to bind to attributes but can be swapped out.

Hoping that's useful,

Erik Hennum