Last year we checked different procedures to implement dependencies to find out about the best implementation in UPDF.
We did a review of dependencies these days. This includes the schema design as well as the specification (not yet on the web, will be end of week).
Although we polished some areas for the final step of the draft version, we did not change the basic idea.
We had some objectives:
1. Where to list dependencies in the schema?
Theoretically there are two possible solutions.
Either you assign them to the feature to be checked once it gets the focus.
Or you list all dependencies in a common pool.
We stay with the original approach of a common pool.
Advantages are maintenance (easier to be checked than looking all over the place) and extensibility. The latter is a unique feature of UPDF, as optional units and/or a user policy could have additional dependencies (dependencies of the master description cannot be removed nor edited).
A recommendation to the driver: A dependency of an optional unit or user policy should have priority. However in a perfect design there would not occur any conflict.
General driver procedure: First check, if there is a dependency with a FeatureCondition of the currently selected feature. Second check, if there's an action defined in any of the hits with the currently selected feature declared as the dominant feature.
2. Why a dominant feature?
Yes, we could have split up all dependencies and listed them depending on the feature with the focus.
However we wanted to design a compact structure, which groups related dependencies properly. If there are dependencies with three or more features involved, but different actions depending on which feature has the focus, we were concerned that listing all required combinations separately would confuse the reader and developer of the device description, especially, if the list is not properly ordered.
And it narrows the number of candidates for the driver once it hits a FeatureCondition.
3. Extended functionality.
We wanted to support functionality commonly available in a number of contemporary driver concepts.
This includes messages as well as hints for info buttons, mandatory selections of settings of features based on a dependency and indications that the appearance of a feature should change, once the dependency is resolved.
4. Conversion between different concepts.
We always have in mind that dependencies (sometimes called constraints) are defined differently in various concepts.
We are positive that a conversion from or to UPDF is always possible and not ambiguous, although you may loose some functionality when converting to other standards.
Check it out!
Regards
Norbert Schade
Norbert Schade
69 Prescott Drive
North Chelmsford
MA 01863
phone: 1-978-251-1017
email: norbertschade@comcast.net
This archive was generated by hypermail 2b29 : Wed Jan 28 2004 - 13:23:32 EST