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
norbertschade@mediaone.net
This archive was generated by hypermail 2b29 : Mon Feb 11 2002 - 11:58:30 EST