I've Got A Hammer...

[Frank Dawson <fdawson@xxxxxxxxxxxxxxx>]

Alec:

The data typing seems to require that the type definitions (ie, new properties) 
be cast as:

1. One of these proprosed standardized data types (eg, INTEGER, FLOAT, etc), or 
2. As a new registered data type (ie, via IANA processing), or 
3. As a non-standard data type (eg, X-xyz-FOOTYPE). 

This will make it somewhat cumbersome to define a new type such a structured or 
multi-valued type (eg,  a property with the form of: 
FOOTYPE:myname;me@host;OWNER;CONFIRMED or BARTYPE:date;date;date;date). 

Now, most folks are just not going to go to the trouble of defining a new data 
type with the IANA. This is a pain. They will also realize that the 
non-standardized data types have a small hope in being accepted by 
implementations. This leaves the low easier approach which is to use the 
existing "nail" to solve the data representation problem.

Who have we helped here? It seems to me we have just limited our data 
definition capabilities. That is why data representation grammars go to the 
lengths that they do to allow for constructed types. Now if we go down that 
line of thinking, we are back to using NDL, ASN.1, Crocker's STIF, etc.  But, 
this does not seem like a low cost, low chat approach to this problem. In the 
"application/directory" domain we already have LDAP to address this.

So...that is the thoughts behind my reference to the "nail" and "hammer".

Cheers.

- - Frank Dawson