[aprssig] spaces in object names

[Pete Loveall AE5PL Lists]

I also find multiple underscores distasteful.  And multiple periods.  And multiple commas.  And parenthesizes.  And braces.

Now before everyone gets all up in arms, I am saying that A___N is just as hard to visually distinguish from A____N as A   N is to visually distinguish from A    N especially if they have any visual distance separating them.  And most display make .... hard to distinguish from ,,,, or ((( from {{{.  Multiple embedded spaces aren't the problem.  It is multiple any character or similar characters in most displays that create visual ambiguity.  We can attempt to warn against them in the spec but maybe a better statement would be "Creators of Object names should be aware of the visual ambiguity that certain character combinations may incur."  I can come up with a lot more combinations, many of which do not involve any repetitive characters.

IMO, what started this thread was someone taking to an extreme a mistake that most all of us as software authors have done with regards to Objects and Items.  The question originally posed (privately but it has been brought up here already so I paraphrase the original question here): "Is there a difference between 'AE5PL' and 'AE5PL    '?"  The answer is "Yes" according to the spec (which some have said we should not take so literally).  The problem is we (myself included) as authors have -assumed- that we can consider stations and Objects as being the same.  We display them the same.  We store them in the same tables.  We therefore equate Object names to station callsigns.  In fact, IMO, this has been a great disservice to the APRS community.  An APRS station is an -active- transmitter (or APRS-IS client) that may have two-way communications capability.  An Object is something created by an APRS station that has no APRS communications capability and may (quite often) represent non-amateur radio or at least non-APRS entities.  What we as authors have done is blur this distinction by storing Objects in the same tables as stations, keying on the Object name, and displaying Objects in such a way as to be unable to discern the mandatory 9 character length of an Object name.  This could have been done by not trimming trailing spaces and displaying Objects with enclosing quotes or any other enclosing delimiters.  But we (all of us) were too smart for that and display and store Objects in such a way as to force ambiguity.

I am in no way condemning any individual in this post.  We (database and software authors) all have done it.  Now we are faced with how to make it a bit more palatable to the general user base.  Do we do this by imposing draconian restrictions in a spec addendum that will have no effect on much of the software that is currently in the field?  Or do we moderate the ideas put forth to best make use of existing clients while not imposing new restrictions on creative authors coming on the scene?  Personally, I am a proponent of the latter.  I have maintained throughout this thread that while we should have followed the spec, we as authors didn't.  As admitted in this thread, many authors, myself included, trim trailing spaces from Object names and I would guess that if communicated with in a nice way, we would find that most of us have programmed our software to display and store Objects in much the same way we display and store stations causing this visual and data ambiguity.

Where this thread, IMO, got off-track was to extrapolate that reasoning to a "we have to ban embedded spaces" or a "we have to ban multiple embedded spaces" for whatever justification.  As I have shown above, visual ambiguity is going to exist because we, as authors, have made our software that way and it is not limited to spaces or multiple spaces.  With the "authors can disregard trailing spaces in Object names" statement, we are at least indirectly acknowledging that we have introduced data ambiguity by storing and displaying Object names in an indistinguishable manner from station callsign-SSIDs.  Unfortunately for the APRS community, this is done and would be virtually impossible to reverse.  On the other hand, no such assumptions have been made regarding what an Object name can contain and in what sequence.  I think it will be a nightmare for Bob to have to continually modify his addendum every time someone says "this looks ambiguous on my display so we need to ban it or at least discourage it".  Wouldn't it make more sense to leave it to the software authors (how do you do a pop-up with a non-GUI client?) to determine how to encourage "unambiguous" names?  Maybe a statement like the one I proposed in my second paragraph of this post?

BTW, what can make this more confusing is if we consider Objects and Items as separate entities from stations in our display and storage, then we also have to consider Objects and Items as separate entities period because of the difference in naming requirements for the two packet types.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On
> Behalf Of Lynn W. Deffenbaugh (Mr)
> Sent: Wednesday, August 12, 2009 10:44 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] spaces in object names
> 
> Curt,
> 
> Well said!  And I'd add that the spec recommend that the pop-up warning
> include some language describing the "why" of the recommendation, that
> it can introduce ambiguity in displays.
> 
> Curt, WE7U wrote:
> > On Wed, 12 Aug 2009, Steve Dimse wrote:
> >
> > "Discouragement" perhaps should even go as far as a pop-up warning
> > box during creation which warns the operator about the "improper"
> > practice.  The client software should not disallow the creation, but
> > should make it more difficult, with a specific choice by the
> > operator to continue in that case.
> >
> > This sort of operation should decrease the accidental creation of
> > like-named objects in a stressful situation yet not go as far as
> > changing the string as received.  I find combining multiple embedded
> > spaces into one space quite distasteful.