At least in the copies and zooming percentage we need variable parameters instead of fixed entries.
We have to agree on a general solution for that kind of problem.
I mentionend the item a number of times. There was little to no feedback.
There are few ways to do it:
1. We predefine a keyword like 'variable-integer' for use in a classifying attribute. I'm open for a different term.
1.1. The question is now whether we should change the attribute name 'Copy_ID' and split it into 'Predefined_ID' (available entries would be 'variable-integer' and 'proprietary-value' to follow our typical procedure) and Proprietary_ID. Same for percentage.
2. For features which may have variable entries we add two attributes 'Minimum' and 'Maximum'. It will always be exactly these names. A slight detail would be whether we assure the driver that the attributes Minimum and Maximum always refer to an attribute Proprietary_ID??? That would mean attributes specifying a min/max for other attributes must have a different name. I could imagine that some people like that.
Just to say it explicitely: We decide upfront in our schema, which features have flexible entries and which don't. The developer editing the xml cannot change that. I think that's realistic.
2.1. Not a proposal, but possible: we add these two attributes to all features to allow variable entries. But I think this level of flexibility is disproportionate.
We may decide to go with both ideas. that would mean a 'variable-integer' would require two attributes 'Minimum' and 'Maximum'. the driver may fall back to '1' and '100' as default.
Thinking another second about 'proprietary-value' I know that we have a number of synonymous entries in enum lists in the data types. Do we want to change them all to 'proprietary-value' to simplify coding?
We have to think about the default value again for these attributes. We save an unique ID a the default setting (see yesterday). For copies and percentage that's no going to work. The unique ID is not meant to be interpreted, but used as a reference only to identify a record. Fine, in this case we have one record only anyhow, which is variable.
1. We assume the driver knows that something is variable by checking the entry spec of the record and interprets the default value not as an ID, but as a setting of the variable entry.
Hmmm, I don't know, although that was the way I edited it yesterday just to have any entry there.
2. We create another element 'LocaleVariableDefault'. Now it depends a bit how we decide above. If we accept that we decide upfront in our schema (my vote) then we can go with the same attributes Default_Feature and Default_Setting. The driver would know that these two values refer to a Proprietary_ID by the element name.
3. A simply add MediaCopy.Proprietary_ID to the enum list for Default_Feature in locales, which normally only holds ID attributes.
Would be the simplest solution. But the driver has to check the attribute.
This will be decided within the next few hours.
Regards
Norbert Schade
Principal Software Engineer
Advanced Development / Connectivity
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Fri Sep 28 2001 - 10:00:03 EDT