Given that the underlying source data are a in table of language/charset tuples,
the parallel lists is the only reasonable choice, I think.
The sparse lists are meaningless - if you don't know that ISO-8859-1 won't
work with Thai, you could make a lousy assumption. Of course, if we allowed
(eventually) a DMTF CIM method to change current charset *without* changing
current language, then that method would be impossible to implement in the
How about if we DEPRECATE all four properties (current and supported) and
add explicit natural language tags on the XxxDescription localized description
properties in the daughter subunit classes? (Note that ALL CIM strings are
Unicode, so the charset's meaningless anyway for the CIM interface).
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
579 Park Place Saline, MI 48176
PO Box 221 Grand Marais, MI 49839
On Thu, Mar 19, 2009 at 9:38 AM, <Richard_Landau at dell.com> wrote:
> CIM_Printer.CharSetsSupported does not say whether the array should contain
> only unique values or all values in parallel with the
> NaturalLanguagesSupported array. With the current wording, both are
> compliant, but the difference might well represent problems for naïve
>> Since this is an old property, we can't insert a SHALL into it. I think we
> should say SHOULD contain only unique values or SHOULD contain entries that
> parallel the other array, and also deprecate the other representation. Does
> anyone have a strong opinion on which representation we should encourage?
> I'm not clear how clients will use the information, so I don't know which
> would be more useful. Personally, SWAG, I like the parallel lists, since it
> also tells the client which charset is used with which language.
>> Opinions, please.
> Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO Office
> +1-512-728-9023, One Dell Way, RR5-3, MS RR5-32, Round Rock, TX 78682