I have put them at:
http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=AttributePropertyConventionsInDtd
and linked appropriately.
I assume folks are in general agreement with this.
Kedar
Carla Mott wrote:
> Are these conventions documented in the wiki or a web page under
> GlassFish? /I /think it would be helpful to capture this in a more
> visible and
> permanent place.
>
> Thanks,
> carla
>
> Sreeram Duvur wrote:
>
>> Here are some conventions we have applied over the years in evolving
>> domain.xml
>>
>> * Prefer ATTLIST entry for any configuration that you expect to be
>> supported by documentation, CLI, GUI and MBeans
>> * Properties are permitted when you cannot predict the configuration
>> up front, such as for a JDBC Driver
>> * Unstable/Experimental features are supposed to use only properties.
>> * Sometimes, property may be added late in the release cycle for a
>> late bug fix or feature. The module lead is expected to
>> promote it to an attribute in a subsequent release. The earlier
>> property support may disappear over time. In the interface
>> stability taxonomy a specific <property> element is unstable.
>> * Create a holding element if a group of attributes can be clumped
>> together for sharing or just for cleaner separation.
>> * #IMPLIED or #REQUIRED must be specified. In case of #IMPLIED we
>> would like to see the default value explicitly
>> in the DTD, if possible. Sometimes this is not possible (computed
>> default)
>>
>> The above rules with consistent naming conventions has been quite
>> effective so far. Lets try to stick to it.
>>
>> It is true that some elements are bloating with a lot of attributes,
>> like in this case. I don't think we anticipated it.
>> Using optional new attributes is still the best way forward. Creating
>> a sub-element of jdbc-connection-pool is
>> also a good second choice. Adding naming conventions to properties or
>> adding another element called
>> <connection-pool-property> seemed like the wrong things to do.
>>
>> Also if we find ourselves documenting a property over multiple
>> releases and the feature is no longer experimental,
>> we should ask that it be promoted to a documented attribute.
>>
>> Sreeram
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>