At 12:50 06/20/97 PDT, Brian Grimshaw wrote:
snip...
>I am more concerned that the proposed protocol (whether binary or text
>encoded) does not seem to allow representing a set of attributes, or a
>hierarchy of attributes -- without a parser having knowledge of all
>attributes. While encoding the type in the protocol has been raised as a
>solution to this, I think types do not model sets very well and this
>should be treated as a separate issue. This could be handled in the
>protocol and, minimally, there should an accommodation for future
>extensions that may allow this without breaking parsers of IPP 1.0.
I'm not exactly sure what you mean by a set.
If you mean a set of values of the same type, then the current
multi-valued encoding works just fine for a set.
In the example in the minutes, there were a set of 2 values for the
"finishing" attribute:
The following is an example of a Print-Job request
"0100Print-Job" CRLF
"job-name 3 foocopies 1 2document-format 22 application/postscript"
"finishings 5 staple 5 punch" CRLF
"%!PS" ...
If you mean a set of attributes then that is another matter. One way
to handle a set of attributes is to have a new data type that is
a single attribute (name and value). When such an attribute has
multiple attributes as values, use the multi-valued mechanism of IPP,
one value for each attribute. In this approach, each (sub-)attribute can
only be single-valued.
An example of an "address" attribute whose value consists of attributes:
"name", "apartment-number", "street", "city", "state", "zip", "country"
would be in ABNF:
"address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA"
A second approach is to define the new data type as a set of attributes.
In the above example, the value of the "address" is single valued.
But it could be multi-values, providing multiple addesses.
"address 52 name 8 John Doestreet 8 123 Maincity 2 LA state 2 CA"
With either scheme in order to group a set of attributes, you need to
define an attribute with the new data type. But since Printer MUST
reject any attribute that they don't understand, a client can only
successfully submit a new attribute with a new data type to a Printer
that supports the new data type.
Is this what you mean by a set? If so, I think we can have sets
in the future with the current encoding and extensibility rules.
Tom
>>If I am wrong about this, can someone tell me how to do it with the
>proposed protocol or where in the various documents this is described?
>>Brian
>>>--------------------
>Brian Grimshaw
>Apple Computer, Inc.
>brian at apple.com>>