We all know the history of this debate (XML or not XML). We decided to keep
the current protocol for IPP1. The informal consensus in maui was that IPP2
(which I think the dictionary discussion is aimed at) must be XML-based.
If we dont make that change then we will regret it for ever and ever.
> -----Original Message-----
> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
> Sent: Monday, March 30, 1998 5:51 PM
> To: walker@dazel.com; Tom Hastings
> Cc: ipp@pwg.org
> Subject: Re: IPP> MOD/PRO - simple proposal for providing
> dictionary-like capability
>
> Jim,
>
> I have similar concerns about the use of attributes with parallel values.
> I have this nagging feeling that we are going to regret this direction.
> But thus far it has been the least bad solution that we have found.
>
> We have arrived at this unfortunate point because the current binary
> encoding has painted us into a corner. An XML encoding would
> allow a very simple solution for dictionaries.
>
> We considered having dictionary members appear as normal attributes
> surrounded by begin-dictionary and end-dictionary "values", but this
> solution
> would potentially create name conflicts with names at the top level for
> parsers
>
> that don't know about dictionaries. This solution works if we force a
> version
> change or all existing parsers add support for it.
>
> We considered having a dictionary structure which would be a new type
> whose values are nested in an existing value. For small dictionaries, this
> is the obvious and simple solution, but if we kept the existing limit
> of 1023 octets per value, some dictionaries would be impossible. Picking
> a value that is large enough for all likely dictionaries but doesn't
> burden
> small implementations was difficult and didn't seem to solve the problem.
> We looked at ways to keep the 1023 limit and instead chunk the dictionary
> into multiple values. I had a reasonable but very ugly solution which
> concatenated the chunks together and use "begin-dictionary" and
> "end-dictionary" "values" to indicate the structure.
>
> By turning the dictionary problem into a naming problem, we seem to have
> side stepped all of these issues, but as you point out data structures
> were
> invented for a reason.
>
> Do you have any suggestions for what we should do?
>
> Bob Herriot
>
>
>
>
> At 01:16 PM 3/25/98 , James Walker wrote:
> >Tom Hastings wrote:
> >>
> >> For the IPP telecon, Wed, 3/25:
> >>
> >> Roger, Bob, and I have been working on various dictionary proposals.
> >>
> >> ...
> >>
> >> Briefly, the scheme isn't really a dictionary at all (previous
> >> versions were). Other earlier versions were adding a new addressing
> >> mechanism for attributes in dictionaries.
> >>
> >> This proposal adds no new addressing mechanisms,
> >> but justs add a new out-of-band value to encode the new Model attribute
> >> syntax of 1setOf 1setOf (doubly nested values). Instead, we use the
> >> idea of attributes with parallel values, like we already have for
> >> "printer-uri-supported" and "uri-security-supported".
> >
> >As discussed in the telecon today, I think that the parallel attribute
> >idea is a bad one... it does not scale well, it is difficult for users
> >to understand and get right, it is error-prone, etc. Our experience
> >from the implementation of parallel attributes in DPA has not been a
> >good one. All in all, I believe that data structures are a good idea,
> >but trying to describe data structures using parallel attributes does
> >not work.
> >
> >> ...
> >>
> >> I've left the rejected example that uses the 'dictionary' attribute
> syntax
> >> in the document. I've also listed the alternatives that we considered
> >> and the reasons for rejecting them.
> >>
> >> ...
> >
> >I simply do not understand why the original concept of a dictionary
> >value tag (with its associated value length) would not work well.
> >This is the example that is shown in Tom's document.
> >
> >...walker
> >
> >--
> >Jim Walker <walker@dazel.com>
> >System Architect/DAZEL Wizard
> >DAZEL Corporation, Austin, TX
> >