Use of a Qualified name, or an actual AttributeType object when in Object-Oriented land seems to be the only way to go. The AttribtueType will need to have knowledge of its QName for document generation. It is worth pointing out that this is required to suport super types, as the same name may be under different restrictions depending on what type it originated from.
Name breaks down in the presents of super types, we require super types and thus cannot expect name to work in all situtations. However it is so direct we should include it in our API as a convience method.
Index based IDs do not work when used with super types, we require super types and thus cannot support them in the general case.
However: many applications call for a flat feature model, we may be able to prove those with simple data with a simple API to access it.
I recommend support indexed based access at the GeoTools level in order to ease migration pain. This can be accomplished by declariing a "FlatFeatureType" and "FlatFeature" model, so we can explictly model simple data.
XPath support at the model level is desirable from a client code point of view, however no implementations to date have managed to produce. Further more if we expect XPath to work our "chain" becomes only as strong as the weakest implementation. We would do better to have a strong Feature Model and construct our XPath support at arms length (using JXPath from Jackarta is the reccomended course of action).
There are downsides to this practice of making values typed by qualified anme, in GeoServer a lot of trouble is spent munging FeatureType/AttributeType information for writing - by strongly typing the players involved we are making the process more difficult (but more specific). We hope the trade off is worthwhile.
and support for is recommended for a simplified FlatFeature.