I have a schema that has <xsd:element name="Size" type="xsd:long"/> #10

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@dysinger

& erlsom_write wont write a string or an integer for it unless I use this patch
original schema: http://doc.s3.amazonaws.com/2006-03-01/AmazonS3.xsd

@dysinger dysinger I have a schema that has <xsd:element name="Size" type="xsd:long"/>
& erlsom_write wont write a string or an integer for it unless I use this patch
schema: http://doc.s3.amazonaws.com/2006-03-01/AmazonS3.xsd
c5ca9fc
@willemdj
Owner

Hi,

I am not sure I understand the problem. Can you give me some additional information, or an example?

Note that you have to provide a string value ("11344503485048") for long types. I realize that this was not a great choice, but that is how it is at the moment. Did you try that?

Regards,
Willem

@dysinger

The case statement & guards in the current code accept only is_integer and is_tuple though. That's the problem. It would not accept a string.

Sent from my iPhone

On Feb 17, 2012, at 6:08 AM, willemdjreply@reply.github.com wrote:

Hi,

I am not sure I understand the problem. Can you give me some additional information, or an example?

Note that you have to provide a string value ("11344503485048") for long types. I realize that this was not a great choice, but that is how it is at the moment. Did you try that?

Regards,
Willem


Reply to this email directly or view it on GitHub:
#10 (comment)

@willemdj
Owner

Hi,

I don't think so. It looks inside a list. If it finds an integer, it concludes (or maybe I should say: assumes) that the list is a string. If it finds a tuple, it concludes that it is a list of nested types. It is a bit clumsy, perhaps, but I think it works. Did you try using a string as value for the long type?

Regards,
Willem

@dysinger

Yes I tried both integer and string. Both of them blew up. With integer
it complained that the type in the schema was long. With string it blew up
with the case statement not having anything but is_integer and is_tuple. I
can reproduce it for you if you like. (not trying to be a know-it-all).
Give me some time & I'll send you an example if you like - for now I'm
using my fork because it works (with a string "long" and the patch I sent).

On Sat, Feb 18, 2012 at 7:32 AM, willemdj <
reply@reply.github.com

wrote:

Hi,

I don't think so. It looks inside a list. If it finds an integer, it
concludes (or maybe I should say: assumes) that the list is a string. If it
finds a tuple, it concludes that it is a list of nested types. It is a bit
clumsy, perhaps, but I think it works. Did you try using a string as value
for the long type?

Regards,
Willem


Reply to this email directly or view it on GitHub:
#10 (comment)

@willemdj
Owner

Hi,

It would be helpful to have an example.

Thanks,
Willem

On Sat, Feb 18, 2012 at 8:15 PM, Tim Dysinger <
reply@reply.github.com

wrote:

Yes I tried both integer and string. Both of them blew up. With integer
it complained that the type in the schema was long. With string it blew up
with the case statement not having anything but is_integer and is_tuple. I
can reproduce it for you if you like. (not trying to be a know-it-all).
Give me some time & I'll send you an example if you like - for now I'm
using my fork because it works (with a string "long" and the patch I sent).

On Sat, Feb 18, 2012 at 7:32 AM, willemdj <
reply@reply.github.com

wrote:

Hi,

I don't think so. It looks inside a list. If it finds an integer, it
concludes (or maybe I should say: assumes) that the list is a string. If
it
finds a tuple, it concludes that it is a list of nested types. It is a
bit
clumsy, perhaps, but I think it works. Did you try using a string as
value
for the long type?

Regards,
Willem


Reply to this email directly or view it on GitHub:
#10 (comment)


Reply to this email directly or view it on GitHub:
#10 (comment)

@willemdj
Owner

Closing this - I still think it is some kind of misunderstanding. Feel free to open a new issue anyone who still thinks this is a problem...

@willemdj willemdj closed this Aug 12, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment