My vote is to go with "optional common text strings" for two reasons. First
is that User Policies shouldn't have to have these elements and this takes
care of that problem. Second is that implementations are going to vary
widely and we don't know exactly what strings are going to be required.
Since we can't come up with them all and we don't know if all the ones we
define are going to be used, it doesn't make sense to me to make them
required. Also, we'll probably find many UPDFs that get written for a
specific drivers. It doesn't seem right to require elements that are known
to be unused in the target environment.
Jim
At 2/11/2002 11:57 AM, Norbert Schade wrote:
>The overall structure of locales has proven to be good. Today we
>implemented some small modifications based on input we gathered over time.
>The corresponding schema and samples are on the web. Please access from
>the UPDF site.
>
>1. Section titles
>As the number of entries grew over time, it turns into an advantage to
>have section titles when working with a XML editor. This will not effect a
>simple text editor.
>As you can see all locale elements referenced from unit descriptions are
>now gathered under ReferencedLocaleElements.
>Instead of facing on huge list of elements you can now close a section you
>are not working on. This is not really a structural change.
>
>2. Popular text strings not referenced by unit descriptions
>We'd like to ease the acceptance of the text string handling we provide in
>UPDF.
>Although a huge number of strings can be referenced from unit descriptions
>we acknowledge that there are more in use in today's drivers. These are
>typically hanlded in defines in header files.
>We offer a chance to specify those, which are very popular between
>drivers, in a special section.
>2.1. Mandatory text strings
>The current implementation includes a new section MandatoryLocaleElements
>(alternative title could be RequiredLocaleElements). This is a list of
>predefined elements with fixed Name_ID attributes. By this method we can
>help with the validation that each locale provides exactly 100% of those
>text strings considered mandatory and defined as such by the UPDF standard.
>A driver could rely on finding corresponding entries.
>In this case a locale referenced by a an optional unit or user policy must
>also provide 100% of all entries - even if unchanged.
>We've added two elements as a sample. Check that the attribute entry is
>identical to the element name in each case.
>2.2. Optional common text strings
>Another way to implement it would be to predefine a list of Name_ID
>attribute values in the data types schema, but leave it to the developer,
>which of them he/she wants to provide for consistency (in a locale
>referenced by a device description - not an optional unit or user policy
>description - we'd seriously recommend to create elements for all of
>them). We would provide standard LocaleElement elements (in this case they
>don't have to have different names) under a section titled like
>CommonLocaleElements. In this case we can't help with a validation whether
>the list is complete. But an optional unit or user policy description
>would not have to list them again redundantly (in fact I'd rather be
>reluctant to overwrite them at all).
>
>Both ways have its advantage.
>We collect a list of proposals for common text strings over the next weeks.
>
>3. Proprietary text strings
>This is another section to help with the acceptance of the format by
>consistent handling of text strings.
>We want to further allow storing any text strings used by a driver, as we
>think the localization within UPDF is highly optimized.
>So a driver developer could communicate all text strings defines to the
>UPDF developer, in which case the driver does not need any other defines
>in header files or anywhere else. This might likely be used when the
>printer manufacturer, who is supposed to develop the UPDF description, is
>the driver developer as well.
>Keep in mind that these proprietary string are not likely to be used, if
>the UPDF description is rather meant to be anonymous, which means it shall
>be used by any UPDF capable driver.
>I would especially use this section, if a printer manufacturer tends to
>write its own UPDF driver or cooperates with one driver developer for most
>of the drivers.
>
>This could also be the proper place to store error messages, which are not
>part of UPDF. We recommend some self-chosen discipline like specifying all
>UI string with a prefix 'UI_String_' and all error messages with a prefix
>'Error_Messages_'.
>
>4. Generic locales defaults
>Since we have an ID per feature, this is no more necessary and has been
>removed.
>
>As standard features like Media size, etc. have a predefined feature ID,
>but generic features can be given any string as a feature ID, we could
>split the Default_Feature attribute into two separate ones:
>Predefined_Default_Feature and Proprietary_Default_Feature. This should
>sound familiar to you from other functionality.
>
>
>Please check the schema and the samples and respond to this email.
>Especially send your proposals for common Name_ID attributes. We will
>revisit locales end of February. So that's the deadline for changes.
>
>Norbert Schade
>69 Prescott Drive
>North Chelmsford, MA 01863
>978-251-1017
><mailto:norbertschade@mediaone.net>norbertschade@mediaone.net
This archive was generated by hypermail 2b29 : Tue Feb 12 2002 - 07:49:23 EST