attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4611.1300" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT size=2>The overall structure of locales has proven to be good. Today we implemented some small modifications based on input we gathered over time.</FONT></DIV> <DIV><FONT size=2>The corresponding schema and samples are on the web. Please access from the UPDF site.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>1. Section titles</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2>As you can see all locale elements referenced from unit descriptions are now gathered under ReferencedLocaleElements.</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>2. Popular text strings not referenced by unit descriptions</FONT></DIV> <DIV><FONT size=2>We'd like to ease the acceptance of the text string handling we provide in UPDF.</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2>We offer a chance to specify those, which are very popular between drivers, in a special section.</FONT></DIV> <DIV><FONT size=2>2.1. Mandatory text strings</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2>A driver could rely on finding corresponding entries.</FONT></DIV> <DIV><FONT size=2>In this case a locale referenced by a an optional unit or user policy must also provide 100% of all entries - even if unchanged.</FONT></DIV> <DIV><FONT size=2>We've added two elements as a sample. Check that the attribute entry is identical to the element name in each case.</FONT></DIV> <DIV><FONT size=2>2.2. Optional common text strings</FONT></DIV> <DIV><FONT size=2>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).</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Both ways have its advantage.</FONT> </DIV> <DIV><FONT size=2>We collect a list of proposals for common text strings over the next weeks.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>3. Proprietary text strings</FONT></DIV> <DIV><FONT size=2>This is another section to help with the acceptance of the format by consistent handling of text strings.</FONT></DIV> <DIV><FONT size=2>We want to further allow storing any text strings used by a driver, as we think the localization within UPDF is highly optimized.</FONT></DIV> <DIV><FONT size=2>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.</FONT> </DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>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_'.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>4. Generic locales defaults</FONT></DIV> <DIV><FONT size=2>Since we have an ID per feature, this is no more necessary and has been removed.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Norbert Schade<BR>69 Prescott Drive<BR>North Chelmsford, MA 01863<BR>978-251-1017<BR><A href="mailto:norbertschade@mediaone.net">norbertschade@mediaone.net</A></FONT></DIV></BODY></HTML>