Re: Next YAML: drop equality definition

I think you are missing the point of what is _allowed_ and what is
_required_.

Take your div example:

  div:
  - !textDomElement foo
  - !textDomElement foo

As opposed to:

  div:
  - &A !textDomElement foo
  - *A

The YAML processor is free in level 2 to use the same abstract graph node
in both cases.

The application is free to construct two different-identity DOM elements -
again, in both cases.

There is no conflict.

That is, the application should not _rely_ on being given a different
abstract nodes graph in the two case above. This does _not_ force it to use
the identical DOM element.

You are taking a restriction of level 2 and projecting it to layer 3 - like
I said, most of this thread is just applying a rule of one layer to another
layer where it does not apply.

Hope this help,

Oren.


On Tue, Mar 8, 2016 at 1:07 PM, Osamu TAKEUCHI <[email protected]> wrote:

> 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
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>

------------------------------------------------------------------------------
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

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core