Re: Next YAML: drop equality definition

Osamu TAKEUCHI <[email protected]> Tue, 8 Mar 2016 20:07:48 +0900
Newsgroups gmane.text.yaml.general
Message-ID <[email protected]>
Oops,

> So, we should try to solve all unsafeties of such use
> cases.

should have been

> So, we should _not_ try to solve all unsafeties of such use
> cases.


In addition, "!float" should have been "!!float".

Sorry for the mistypes.

Best
Osamu Takeuchi


On 2016/03/08 20:01, Osamu TAKEUCHI wrote:
> Oren,
>
>> Actually, I don't see how a YAML library can _unintentionally_
>> discard identities of scalar nodes with custom tags. Could you
>> show an example?
>
> I found an example by myself.
>
> A YAML document,
>
> - &A 3.141592653589793238462
> - *A
>
> is usually loaded as
>
> [!float 3.141592653589793238462, !float 3.141592653589793238462]
>
> in many YAML systems. Here, the identity of &A is lost.
>
> The problem is, this document can mean
>
> - &A !not_float 3.141592653589793238462
> - *A
>
> by an implicit tag resolution with some customized schema.
>
> If a schema-blind tool loads the document and save as
>
> [3.141592653589793238462, 3.141592653589793238462]
>
> and !not_float requires identity preservation, the document
> is broken.
>
> I see what is unsafe to store some data that needs identity
> preservation into a YAML scalar.
>
>
> As far as we only have this example, the remaining issue
> is how much we expect for schema-blind tools.
>
> If a schema-blind tool load and save the document like
> above, the user will not be happy anyway, even if the
> node is indeed of !float. If the document is written
> with anchors and aliases, the user will not want any
> schema-blind third-party YAML tools to destroy the
> identity anyway.
>
>
> Another point is, if a schema-blind tool loads the value
> as !float and save it as
>
> - 3.14159265359
> - 3.14159265359
>
> the document is also broken. Note that the trailing digits
> are rounded due to the limited precision of native float
> type.
>
> If a schema-blind tool loads and saves a YAML document,
> there are so many unsafeties besides scalar's identity.
> So, we should try to solve all unsafeties of such use
> cases.
>
>
> I appreciate your comments.
>
> Osamu Takeuchi
>


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval