Semantic Model Mail Archive: SM> a composite feature Media

Semantic Model Mail Archive: SM> a composite feature Media

SM> a composite feature Media

Date: Tue Sep 24 2002 - 12:16:20 EDT

  • Next message: Zehler, Peter: "SM> Telecon Minutes from 9/19"

    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
    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.

    This archive was generated by hypermail 2b29 : Tue Sep 24 2002 - 12:17:41 EDT