I think Jim and Erik have done an excellent job discussing the use of
specialized syntax within a singled value attribute to describe an
ordered list. This is an excellent solution for the uri related parameters.
In the specific case of the printer speed (mono vs. color), I'd
prefer to see two separate attributes. The use of a single, syntatically
bound attribute would make it impossible to locate a printer based on
a minimal speed. For example pages-per-minute-mono > 5.
Alternatively, does it make sense to make the speed less "color" dependent,
Using min-speed and max-speed instead?
>> The underlying IPP Printer object attributes 'printer-uri-supported'
>> and 'uri-security-supported' are (and MUST be) ordered lists.
>> If SLP purists insist that we can have no ordered lists as
>> values of a 'printer:' attribute, then we have a serious problem.
>> Separately, I think it would be FAR better to have a
>> 'pages-per-minute-mono' and
>> attributes in the 'printer:' template (perhaps with the
>> monochrome attribute being Mandatory and the color one
>> - Ira McDonald
>> High North Inc
>There is no problem creating ordered lists as values for SLP.
>You can't use ',' to delimit them, though. You create a syntax
>for the lists to delimit the values which is distinct from SLP.
>For instance, you could use ';' as the delimiter.
>In this example, pages-per-minute has two values from an SLP
>perspective "mono;10" and "color;1". You could parse this at
>the client side to be two values which have 'two fields' apiece.
>Parsing them out, you know that the printer has a speed of 10 for
>mono and 1 for color, etc. There is nothing in SLP or the template
>specs to stop you from adding semantics (ordering, etc.) to the
>string attribute values.
Pete St. Pierre
Advanced Development Group
Sun Microsystems, Inc.