Subject: RE: Empty string attribute value

From: Mikael Pahmp <[email-masked]>
Date: Tue, 15 Feb 2000 11:42:14 +0100

> > For an attribute of srting type, there is sometimes the 
> need for sending the
> > empty string. There is however no way of representing it in 
> the 'attr-list'
> > grammar correctly.
> >
> > Probably this was the intention of the author from the 
> beginning but 
> > the grammar rules forbids it.
> 
> Mikael,
> 
> What is this useful for?  It was actually my intention to 
> forbid it :-)
> 
> Not that I like forbidding things for their own sake, but the 
> WG thought 
> of an empty value as a keyword.  We didn't think that an 
> attribute would
> be both a keyword and a attribute-value tuple. 

E.g. when we announce the service:printer service, its attribute values are fetched from the printer but doesn't always have a value for every attribute. In that case, when the attribute is of string type, it would be suitable to send the empty string. I don't know of any attribute right now that would cause trouble if the value was sent as e.g. a single space character.

Thinking more about it I guess if a client really wants to discern between an empty string and one with only white spaces, the attribute should by represented as an opaque value type. Since string comparison strips leading and trailing white spaces before evaluation, strings should not be used when an empty string or an string with only white spaces have significance.

So we'll go back and see if representing an empty string value as e.g. a space character will work for us. One thing that must not happend is that when the value for a string attribute is empty, the attribute is sent as an keyword. That would cause problem in the implicit typing rules, e.g. in the SLP Java API where this types are actually represented by different Java types (classes).

/Mikael

---

From: Erik Guttman <[email-masked]>
Date: Tue, 15 Feb 2000 13:25:43 +0100 (MET)

> E.g. when we announce the service:printer service, its attribute values are
> fetched from the printer but doesn't always have a value for every
> attribute. In that case, when the attribute is of string type, it would be
> suitable to send the empty string. I don't know of any attribute right now
> that would cause trouble if the value was sent as e.g. a single space
> character.
> 

Let's see, there are three attributes A, B and C.  I'm looking for
something where A=1, B=2, C=* (anything).  What you are saying is
just because a given service C doesn't have a value right now, I 
should still find it.

> Thinking more about it I guess if a client really wants to discern between
> an empty string and one with only white spaces, the attribute should by
> represented as an opaque value type. Since string comparison strips leading
> and trailing white spaces before evaluation, strings should not be used when
> an empty string or an string with only white spaces have significance.

Remember spaces are elided with the same rule as LDAP for compatibility.
That is N spaces are the same as one.   

> So we'll go back and see if representing an empty string value as e.g. a
> space character will work for us. One thing that must not happend is that
> when the value for a string attribute is empty, the attribute is sent as an
> keyword. That would cause problem in the implicit typing rules, e.g. in the
> SLP Java API where this types are actually represented by different Java
> types (classes).
> 

I still have problem with the idea that services advertise attributes for
which they don't have a value set.  I would think that if a value is not
set, it wouldn't be advertised.  Searches should be for things which have
certain properties (attributes set to values) not that have attributes 
whatever they may be set to.  

An unset attribute is not really an attribute, right?  It would be like 
if you asked me "How are you?" and I answered "I am."

Erik