Some may call it a Media object.
1. composite features
I think it's a good idea to have the ability to assemble a set of typically
simple features to a higher level - you may call it a compositve feature or
collection or anything else.
2. open architecture
I think people may want to assemble any set of components to a composite
feature depending on their current needs.
I've seen any attempt to predefine the components fail over time. You just
cannot predict the future.
Therefore I recommend to provide an open architecture for assembly.
3. give it some meaning
By definition a composite feature is anonymous. It could be any weird
combination of features.
I see two ways to get out of this.
3.1. Predefine the character of the c.f.
That could be done by specifying special c.f. like a Media object (still
with an open architecture!).
Or by assigning a special attribute with predefined values to the c.f.
structure. One of the values could be 'Media'.
3.2. Define a dominant feature
It is really necessary to understand the character of a c.f., only if the
c.f. is exported.
>From a driver perspective: Only if you report the c.f. to the system, it is
interesting for the system - or applications running on that system - to
understand the meaning of it.
That leaves the detail to investigate: how do you determine that a feature
is not part of the public printing capabilities?
In any case you would certainly want to report a c.f. 'Media'.
I feel that the media size is the main component of that complex feature,
even by history when I see the way applications work generally.
So I'd like to see my Media records reported to that part of the operating
system.
I can do that by just declaring the media size the dominant component of
the Media object. I certainly don't want the Media object reported again to
the system as another feature.
And I would have solved the detail question above as well: if a c.f. does
not have a dominant component, it's likely used for some internal driver
stuff (a realistic sample would be to set some defaults for some controls)
and does not have to part of the public printing capabilities.
4. Silent components
If a feature is a component of a c.f. with a dominant feature, it's either
dominant or silent. Means either this is the feature, which decides how the
end user will see it in applications, or it should not show up in
applications at all.
So the requirement for non-dominant features is to announce themselves
silent. In reality that means the driver better provides some dummy entry
to have something it can report. But the dummy entry should indicate to the
user that he/she cannot select this silent feature, as it is selected by
the dominant feature.
Sample: When you define a Media object, you likely want to select the
records in the media size control of the application (or in the ideal dream
world a Media control). In the media source control - if available - you
should see a dummy entry like 'Selected by media size' (think about a
better string, but you get the idea).
Now you have the first level of functionality working.
5. Conflicting features
One could mess it up - as always.
Imagine the operating system expects the driver to report resolution and
media size as part of the public printing capabilities.
Probably my driver would provide two c.f. 'Quality' (components resolution,
bit depth) and 'Media' (components media size, media source).
Should not be a problem, as their are no conflicting components.
Becomes very risky, if one decides that resolution should be a component of
'Media' as well.
You are in danger to select a feature at two locations with different
settings -> prepare to crash.
So first that is considered very bad practice. But if you have to do it,
work very carefully with dependencies and you can get out safely.
That's my view of it.
Norbert