Re: Allowable characters in xAP parameter values

[Stuart Booth <lists@xxxxxxxxxxxxxxxx>]

On Tue, 29 Mar 2005 15:00:26 +0100, Kevin Hawkins
<lists@xxxxxxx> wrote:

>So just to clarify this am I correct that *values* can only contain
>ASCII characters 0x20 to 0x7E  inclusive and data outside his must be
>sent with !   ??

Seems that way to be technically inline with the spec. However UTF8
encoding isn't completely adequate either and where Unicode is meant
to be the single right answer (I believe?), xAP will have to send
binary values?

What does a low-end device do with an 8-bit character? I guess some
will accept them, others might demand ASCII only.

>BTW "{" and "}" fall within this range  but I dont
think that is a
>problem is it for well written xAP applications  ??  (as values can
only
>end with chr(10))

Indeed, I seem to recall that anything after the = separator is a
valid value component until the end of line. I'd assign that as a bug
if my own s/w read a } mid-line and terminated the message. I ought to
add that to my test framework actually.

>Is there an absolute feeling against allowing 8 bit data to appear in
>char values  except chr(10) ?  <ducks> as me expects there is
;-). Bear
>in mind serial data on an RS232 line where XON/XOFF flow control
>problems exist could be encoded differently.

If one xAPp chucks out UTF-8 and another reads in UTF-7, aren't the
results undefined?

>Does UTF8 encoding adhere to  this range 0x20 to 0x7E  ??

Do you mean it would read those (UTF-7) values correctly? I think yes,
but I have to say I've not experimented with this at all.

>I wonder what happens with ! currently - do people handle this OK and
>will it break existing apps ?? (it shouldnt I guess but I feel certian
>it will ).

I haven't tested this code in a long while, although I'm sure my
testing framework had some coverage for it. I've never used it for
anything myself. But if it's broken as you suspect, I'll fix it
(tomorrow :).

>Reason is our first 'serial data' schema is imminent for the RS232
>serial port on the Netiom, and we are talking about whether there
should
>be an 'auto' mode where the serial RS232 data appears as
>data=whatever   but automatically changes to data!A0B1C1FF20  if there
>is content outside the 0x20 to 0x7E range. Is that transparent to
>everyone currently   ??

In the case of xFx you may have to code to accept either - I'm afraid
I can't recall the API to this area (and I wrote it :( !) I mean it
would probably be explicit in the code rather than handled
transparently behind the scenes inside xFx. I'll have a look into this
as it's interesting. It could (should!) work with 8 bit strings
internally but on transmission of a xAP message transcode to ! values
instead of 8-bit = strings. I'm almost certain that it doesn't do this
currently. As I've never used it before I've never noticed this
annoyance.

Would you want to read the xAP message in Viewer in its raw ! mode or
decoded = flavour. A toggle b/w them I guess with some auto-detection
visual indicators.

>I guess it should work with everything but I know I personally haven't
>allowed for it so you couldn't send
>
>STATE=ON   or STATE!6F6E and it work inside a BSC command to my xAP
>C-Bus gateway

If all the xAP developer kits supported this implicitly would you have
to concern yourself with it? I only know the API to xFx though
(surprise!).

I do recall that in xFx you don't actually explicitly use the = or !
characters as name/value pair separators in your code. Instead the raw
values are wrapped up in special classes, which is what should
hopefully enable me to allow you any UTF-8 value and let the framework
deal with it underneath, which seems like the right answer in many
cases. I don't know how I'd automatically detect Unicode at this stage
though, I'm not familiar enough with the details of the encoding world
(Value#<ValueInBinaryUnicode> perhaps?)

I'll do some experiments imminently.

S
--
Stuart Booth <stuart@xxxxxxx>
xAPFramework.NET - a xAP software development framework for .NET

http://www.xapautomation.org/ 
     http://www.xapframework.net/