Conference azur::mcc

No ordering  is  defined for FullNames but equality certainly is.  Note that
the equality determination is not at all trivial.

Phase V has three entities I can think of with FullName identifiers.  I sure
hope MCC can handle these!

Graham

    why isn't FullName ordering defined?
    

    Why? well, because...
    
    Seriously, because simple names have no order. We didn't know how to
    sort binary names against easy names. This was a DNS decision.
    
    Mark

Actually, there *is* an order for SimpleName (see section 1.4.3 of T2.0.2 of
the  DNS  architecture).   It  is  only  FullName  for  which no ordering is
defined.   Actually  �1.4.3  doesn't  make  it  clear  it  only  applies  to
SimpleNames  but the ordering is not well-defined if it is taken as applying
to FullNames.

It would be perfectly possible to define an ordering for FullNames but there
has  never  been  any  need and it has apparently never been done.  What use
would  it  serve?  Note  there is no particularly obvious FullName ordering:
which should be lower: dec:a.b.c, dec:ab.b, dec:a.c, dec:a... ?

Graham

    There is an obvious application of FullName ordering.  Any time you
    have to display a list of FullNames, the obvious thing to do is to
    display them in some kind of sorted order.  Otherwise it's a nightmare
    to search through the entire list of them.   I'll bet you that the
    DNS product already does this if it has any kind of DIRECTORY function.
    Given that SimpleNames have an ordering, what's the big deal here?
    Not that I'm going to lose sleep over it or anything...
    
    					ben
    

    RE:.4
    
    Why not think of it as describing the path in a tree structure.  Then
    ordering (at least to me) becomes intuitive.  You sort the root
    portions first. Then the next node down.  Then the next node down, etc,
    until you are done.
    
    So in your example:
    
    which should be lower: dec:a.b.c, dec:ab.b, dec:a.c, dec:a... ?
    
    It would be:
    dec:a...
    dec:a.b.c
    dec:a.c
    dec:ab.b
    
    If you had an ibm: full name, all the dec: full names would come first,
    'cause DEC comes before IBM in the dictionary :-)
    
    -Matt.

Sure, you  can  define  any  number of orderings (I still don't think any of
them  is  "obvious" to a layman).  Internally in my implementation we happen
to  use an ordering that just does a simple lexical ordering of the internal
format  of  the  FullName.   This  would not be acceptable as an architected
ordering  because  "equal"  names  (e.g.  differing in case) get sorted into
different  positions.   However, it meets the particular need we have (to do
with saving state in wildcard lookups).

My point  is just that the architect didn't define an ordering.  If you want
one, go ask in the DNS_ARCH conference!

Graham

Divergence struck quickly on this one! All I asked was why the SRM indicated
FullNames could not be compared. Ordering is an important, but different,
issue.

Having implemented the call that prompted me to ask the question, it is clear
that comparison of FullNames works, and that the SRM is in error.

    DECdns supports comparision of two full names. In fact there is a DNS
    function DNS$COMPARE_FULLNAMES to do that job.
    
    So why not in DECmcc?
    
    Jesuraj

I don't know if there is support in MCC for direct comparison of FullNames,
but mcc_aes_equal works for instances whose identifiers are Fullnames, 
and that is all I needed.