attachment-0001

<html> 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: <blockquote type=cite cite>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 <a href="mailto:norbertschade@mediaone.net">norbertschade@mediaone.net</a></blockquote></html>