|
Since I have rather
strong views on this, I thought I would carefully read the thread and then
provide some insight as to how decisions made in LDAPbis could affect various
fora and standards bodies.
I've now gone
through the thread twice, and still have the same conclusion - prescribing an
attribute name length bound is BAD.
I'm not going to
rehash any of the other arguments, because my feeling is that the WG is at
somewhat of an impasse here. However, I will present an argument with new data,
which is based on **users** wishing to develop directory schemata and finding
that existing implementations have severe interoperability
problems.
There are numerous
standards bodies and fora, ranging from the TeleManagement Forum to the DMTF to
3GPP to a host of XML and Web Services efforts, that have as part of their
standards relatively long names. For those that are using UML (or UML-like)
approaches, this takes the form of very long (> 64 characters is common)
class, attribute, and relationship (e.g., association, aggregation, composition,
etc.) names. The basic way that many of these schemata are designed uses a
standard and simple method to generate the name of relationships:
<object1><verb><object2>. Note that the order may also be
<verb><object1><object2>.
Thus, whether a
class or an attribute name could conceivably be shortened, it is almost certain
that the relationship won't be able to be shortened a sufficient amount to do
any good.
More importantly,
however, as a schema designer, I find it unaccceptable that my schema has to go
through some bizarre machinations when being transformed from an information
model to a data model just so it has a prayer of being implemented in a
directory. This is a great way to encourage people NOT to use a
directory.
The mapping is
difficult enough as it is - coming up with some difficult alias schemes, or
methodology for name shortening, is not conformant to the basic schema that was
agreed to by the standard body or fora in the first place.
Furthermore, once
one "buys into" any type of translation mechanism to produce different names, it
is guaranteed to cause interoperability problems, simply because it is too hard
to guarantee that two different implementations will apply the same rule to
produce the same name.
The examples listed
above cover a very large body of work in different disciplines. Restricting name
length to some arbitrary limit is inherently bad, as it flies in the face of the
standards bodies and fora that are trying to use directories in the first place.
They also exacerbate existing interoperability problems.
This WG might
not have identified issues such as these explicitly as part of its charter, but
it should consider them, since its fundamental purpose is to produce a draft
standard. That requires interoperability.
Please, let's not ruin LDAP as it starts to
mature.
regards, |