records generated from UBF

[Erik Pearson]

Thanks, Ulf ...

some comments below

>
>> Finally, just a quick correction to the spec at
>>
>> http://www.sics.se/~joe/ubf/site/ubfa.html
>>
>> I believe the structure should be defined with comma separators rather
>> than just whitespace
>>
>>      { Obj1, Obj2, ..., Objn }
>>
>> rather than
>>
>>      { Obj1 Obj2 ... Objn }
>>
>> The examples show the comma separators.
>
> I was also confused by the example, but... reading on you will find 
> that
> Joe has defined comma as whitespace:
>
> "For convenience blank, carriage return, line feed tab and comma are 
> treated
> as white space. Comments can be included in UBF(A) with the syntax 
> %...% the
> usual quoting convention applies. "
>
> That is, the commas are optional.

Thanks, I didn't notice the comma sneaking in there as whitespace. 
However, I am still somewhat concerned:

- how do you disambiguate {"Hi" 'greeting', "world" 'planet'}? It seems 
that this could be either {Obj1 Obj2 Obj3 Obj4} or {Obj1 Obj3 Obj4} or 
{Obj1 Obj2}.

I must be missing something crucial here.

I have a new concern too -- how to represent null (i.e. missing, blank) 
values?
For strings it would be
"" $

for constants
'' $

for binary
0 ~~ $

(or
~0~~ $
if the tilde prefix is preferable),

but for integers it would be

  $

.. that is, a blank. But this raises a few issues:

1. How do you carry the type information for a blank integer?

2. Is there a valid concept of typeless null? That is not only is the 
value blank, but it also carries not type information?

3. It seems impossible to represent a null tagged integer -- it would 
be indistinguishable from a plain constant.

Do you or does anyone else have experience with confronting these 
issues?

I can see that UBF(B) might help with some of these issues, since the 
usage of values within a particular context would imply their type. 
However, at this point I'm just concerned with getting plain old UBF(A).

Also, one of the things I'm trying to keep an eye on is places where 
the spec introduces more work for the parser-builder. In my case, I 
would like to use this with multi-vendor data and message exchange. In 
these cases, having a clear, easy-to-implement spec is very important. 
People need to implement this stuff in all sots of weird languages and 
often in a hurry!

Thanks,

Erik.



>
> /Uffe
>
>
Erik Pearson
Adaptations
desk +1 510 527 5437
cell +1 510 517 3122