Re: [Jcardcal] Integers in jCard

Hi Michael, all,

OK, it may be true that checking the validity of floats/integers is an implementation issue that does not require our specification.

Then lets adopt the texts about integers and floats as proposed earlier:

Add to the end of section 3.4.9:

    Note: Neither JSON nor jCard prohibits using a combination of decimals and
    exponents to form an integer number. However, since vCard does not support
    decimals or exponents in integers, any decimals and exponents MUST be
    eliminated when converting an "integer" value type property from jCard to
    vCard.

Add to the end of section 3.4.10:

    Note: Neither JSON nor jCard prohibits using exponents to form
    a float number. However, since vCard does not support
    exponents in floats, any exponents MUST be eliminated when
    converting a "float" value type property from jCard to vCard.

Best regards,
Bert

---
From: Michael Angstadt [mailto:mike.angstadt@gmail.com] 
Sent: 2013年9月2日 21:30
To: Bert Greevenbosch
Cc: Barry Leiba; Philipp Kewisch; jcardcal@ietf.org
Subject: Re: [Jcardcal] Integers in jCard

The header of each section does include a reference to the corresponding section of the vCard specification.  Is that enough?  I agree that these limitations are unlikely to be encountered in the majority of use-cases.

Mike

On Sun, Sep 1, 2013 at 10:19 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:
Hi all,

@Michael: thanks for pointing out the issue with floats. Indeed floats may require conversion too.

There may be some problems with the conversion though. For example, it seems hard to convert a floating point number 3.456*10^-127 to a form without exponential. It is quite interesting to note that the vCard specification RFC 6350 forbids usage of exponentials (scientific notation), but at the same time requires similar precision as binary64.

This does not hold for huge integers, such as 2.84*10^127, as RFC 6350 gives explicit boundaries for integers (9223372036854775807 to -9223372036854775808) and the converter can break off and output an error in case these boundaries are not obeyed. With integers an issue could be a "false integer", which is actually a non-integer number with "integer" value type.

So I guess the jCard to vCard converter needs to make some decisions on which values are acceptable, and for which values it should abort the conversion and generate an error. It may need to round values to a certain precision, in which case there would be some semantic loss. I have the suspicion that this is more a theoretical problem than a practical problem, as in practice arbitrary precision or number height may not be required. However, something could have gone wrong (whether or not on purpose), and implementations should be ready for this.

Before I propose some extra text on this, I would like to gather related opinions?

Thanks and best regards,
Bert

---
From: Michael Angstadt [mailto:mike.angstadt@gmail.com]
Sent: 2013年8月30日 20:59
To: Bert Greevenbosch
Cc: jcardcal@ietf.org; Barry Leiba; Philipp Kewisch
Subject: Re: [Jcardcal] Integers in jCard

On Thu, Aug 29, 2013 at 10:12 PM, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:
To me, it seems impractical to forbid using decimals and exponents for jCard integers. A general JSON parser (which is oblivious of jCard) would ignore any such requirement anyway.

Agreed.  A similar statement should be added to the "float" section (3.4.10) about permitting exponents to be used.

BEGIN
  Note: Neither JSON nor jCard prohibits using exponents to form
  a float number. However, since vCard does not support
  exponents in floats, any exponents MUST be eliminated when
  converting a "float" value type property from jCard to vCard.
END;

Perhaps these changes should be applied to the jCal draft as well, since jCal also defines "integer" and "float" data types.
_______________________________________________
jcardcal mailing list
jcardcal@ietf.org
https://www.ietf.org/mailman/listinfo/jcardcal