To test my understanding of your concern, I summarize the two problems
you address in the form of objectives.
* The first is to distinguish two attributes that have the same name --
the example you give is "address".
* The second is a representation of attributes that consist of multiple
pieces of information (sub-attributes) that can be easily distinguished.
I think the first goal is best achieved by having meaningful names for
attributes. The human readable form of attributes is already a reason
for meaningful names and all attributes are specified as having a type.
For example, there are attributes for "job-originating-host" and
"job-originating-user" which are both 'names'. It is unlikely that both
of these (or either of these) would be called "name" and, similarly, it
is unlikely that shipping address would be called "address". In this
example, "address" is best considered the attribute type and "ship-to"
could be an attribute of type 'address'.
The second goal seems to be (almost) handled by the sentence in the HTTP
1.1 Transport Mapping document that says "An attribute whose value is a
set of n values shall be represented as a sequence of n attributes, where
all but the first attribute have a name of zero length." This specific
representation could be debated, but if simplified to not have the
restriction of zero length attribute names for all but the first
attribute, then this would permit an arbitrary hierarchy of attributes.
This syntax would be represented as:
attribute = name-length name value-length value
...
value = octet-string | attribute
The implicit type of an attribute is sufficient to know if it has a value
of multiple attributes.
There IS a goal I can think of (not to suggest this should be a goal)
that would justify your proposed solution. If you want to be able to
programmatically process (perhaps in a UI application) a set of
attributes, you would need the type information to be explicitly
represented -- but you would not need to know the attribute names. The
meaning of an attribute value would still require a priori knowledge of
the attribute name, but much can be done without that.
If this is not intended, I see the value-type as redundant. If this is
intended, I suggest that all types (as specified in IPP) be represented.
Brian Grimshaw
Apple Computer, Inc.
brian@apple.com
>The Problem Statement
>
>To avoid vague generalizations, lets consider an example that I believe
>is likely to arise in the near future. On attribute one might want to
>add is an "address". For example, one might have an address to which the
>final output is to be mailed or shipped. One might also have an address
>to which the bill for reproduction is to be sent. This brings our first
>problem because, quite often, these two addresses are not the same.
>That means that we need two different address attributes.
>
>The second problem with addresses is that an address is a structured
>entity. It has things like a mailstop, a street number, a street name, a city
>sub-region identifier, a city identifier, a state and/or country
>identifier and, typically, some kind of ZIPcode. These are assembled
>into an address, but they are assembled in different ways in different
>cultures and countries. This means that treating the address as a single
>character string makes it very difficult to accurately recover the
>information in the address. It makes more sense to store the address as
>a structured objects with attributes and values for each of the
>component parts. But, the address (as a whole) is the value of the
>shipping address or billing address attribute identified above. The
>current proposal for IPP does not allow a value to be structured.
...
>A Proposed Solution
>
>The proposed solution to the extensibility problem is to add a type byte
>(or half word) to the value portion of the value portion of the
>attribute-value pair. This would change the syntax in Randy's recent
>draft as follows:
>
>attribute = name-length name value-type value-length value
>...
>value-type = one-byte integer ; a registered type value
>value-length = three-byte integer ; number of octets in value
>value = octet-string
>
>Note that the length was increased to three bytes to allow for larger
>structured values and was (arbitrarily) made three bytes so that the
>combination of value-type and value-length takes four bytes.
>
>It is proposed that there be a registry of value types. The first two
>entries in that registry would be (zero is reserved)
>
>1: Unicode string in UTF8 encoding (as specified in the draft)
>2: list of values (here the length of the value field determines how
> many values are present. The length, however, is not the number of
> value, but the number of bytes consumed by the values.