You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2007/01/03 23:22:14 UTC

Re: XML longstr mapping

On Wed, 2006-12-20 at 19:14 +0000, Robert Greig wrote:
> On 20/12/06, Kim van der Riet <ki...@redhat.com> wrote:
> > Ok, will do - byte[] it is.
> >
> > Perhaps we should change the term "longstr" in the spec to "binary" or
> > something similar. It would be less confusing.
> 
> I fully agree. I tried arguing this point in the past without any
> success. I think the argument was "C programmers think of strings as
> byte arrays"...


+1, longstr is misleading and it is entirely unfair to blame C
programmers! The type in question is a length-prefixed byte array. There
are no guarantees in the spec about being able to treat it as any type
of string. 

I did a quick search and couldn't find a formal definition for longstr
in the spec - I must be blind, where is it?

Cheers,
Alan.


Re: XML longstr mapping

Posted by Carl Trieloff <cc...@redhat.com>.
Alan Conway wrote:
> On Wed, 2006-12-20 at 19:14 +0000, Robert Greig wrote:
>   
>> On 20/12/06, Kim van der Riet <ki...@redhat.com> wrote:
>>     
>>> Ok, will do - byte[] it is.
>>>
>>> Perhaps we should change the term "longstr" in the spec to "binary" or
>>> something similar. It would be less confusing.
>>>       
>> I fully agree. I tried arguing this point in the past without any
>> success. I think the argument was "C programmers think of strings as
>> byte arrays"...
>>     
>
>
> +1, longstr is misleading and it is entirely unfair to blame C
> programmers! The type in question is a length-prefixed byte array. There
> are no guarantees in the spec about being able to treat it as any type
> of string. 
>
> I did a quick search and couldn't find a formal definition for longstr
> in the spec - I must be blind, where is it?
>
> Cheers,
> Alan.
>
>   


Just checked, there is no doc - so we should take to the working group 
to fix. I also agree we
should rename it. If we are in agreement we should cross post it to the 
AMQP working group
list.


RE: XML longstr mapping

Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2007-01-03 at 17:42 -0500, Tomas Restrepo wrote:
> I'm guessing it's Section 4.2.5.3 "Strings". I also agree the term longstr
> is misleading, but the spec does talk about "short and long strings".
> 
> Actually, the spec is far more misleading, because it explicitly says that
> "short strings" are UTF-8 encoded (i.e. text), while saying that "Long
> Strings" are just a length-prefixed array of octets with no requirements at
> all about the content (so they can carry arbitrary binary data, I guess).

I think the intent and the actual implementations are that:
 - shortstr is a short (<256) UTF8 string.
 - longstr is a binary blob.
 
There is no other string type (e.g. UTF16) although clearly you can
store anything in a longstr, including strings encoded any way you like.

So I think we need to:
 - rename longstr as "binary"
 - change all spec wording (including section 4.2.5.3) so that the
binary type is not referred to as a "string"

Cheers,
Alan.


RE: XML longstr mapping

Posted by Tomas Restrepo <to...@devdeo.com>.
Alan,
 
> +1, longstr is misleading and it is entirely unfair to blame C
> programmers! The type in question is a length-prefixed byte array. There
> are no guarantees in the spec about being able to treat it as any type
> of string.
> 
> I did a quick search and couldn't find a formal definition for longstr
> in the spec - I must be blind, where is it?

I'm guessing it's Section 4.2.5.3 "Strings". I also agree the term longstr
is misleading, but the spec does talk about "short and long strings".

Actually, the spec is far more misleading, because it explicitly says that
"short strings" are UTF-8 encoded (i.e. text), while saying that "Long
Strings" are just a length-prefixed array of octets with no requirements at
all about the content (so they can carry arbitrary binary data, I guess).


Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/