On Wed, 4 Jun 1997, David Goldsmith wrote:
> Is there no provision for "lists" in the protocol as it's defined now?
Only simple lists (there was a long debate to include that much
complexity). Permitting arbitrary structured data in any attribute would
add far too much client complexity -- something which has to be avoided
for ACAP to succeed.
> language, and is much easier to parse than something like HTML. You could
> do something (loosely) like:
>
> ( alternate-names
> (en-us "name1")
> (ja-jp "name2")
> )
I'm well aware of lisp like structuring -- ACAP makes heavy use of it in
the protocol. But if attributes can have arbitrary structure, how is one
to search for a particular value? What's the value and what's the
meta-data?
> Can you think of no other attribute you might want to tag a value with
> than language?
Language is an intrisic characteristic of human readable text which is
mandatory for certain types of processing. I can't think of any text
characteristics other than language and charset that are.
> If one comes up, you'll have to introduce another
> mechanism anyway. And I suspect there are other multi-valued attributes
> than just "alternate names".
>
> >There are *a lot* of attribute-value based protocols including SNMP, LDAP,
> >DHCP, ACAP, RFC 822/MIME/HTTP, etc. In fact, the attribute-value model is
> >a basic tool in protocol design.
>
> I thought LDAP used something like the notation I was tossing around
> above. Maybe I'm thinking of something else...
LDAPv2 doesn't support international text. The current LDAPv3 language
proposal (not yet standardized) is in
<draft-ietf-asid-ldapv3-lang-01.txt>. It basically involves overloading
the attribute name with complex semantics. It's far less expressive than
MLSF, more complicated, and specific to LDAP's data model. It also foists
not-insignificant complexity onto the client -- something that ACAP has to
avoid due to a firm client-simplicity design goal.
As I've said before -- this can be solved at the application protocol
level, but only with far more complexity. Recognizing that language is an
intrinsic property of human readable text and putting it down one level is
the correct solution and results in a superior design.
> The code for dealing with the language tagging might only be 1/2 a page,
> but that doesn't address their needs. You need to figure out how to turn
> that into calls to a speech synthesis engine. But maybe you meant that
> most applications would only need 1/2 a page to ignore the tags, so that
> specialized applications could support blind users?
Exactly. Make the common case simple and the uncommon case possible.
--- Chris Newman <chris.newman@innosoft.com>A paragraph from ASN.1 standard: "The resulting type and value of an instance of use of the new value notation is determined by the value (and the type of the value) finally assigned to the distinguished local value reference identified by the keyword VALUE, according to the processing of the macrodefinition for the new type notation followed by that for the new value notation."
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT