Re: Next YAML: drop equality definition

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

I know the layer issues. I know the current spec do not allow the
application to rely on it. My concern is what the restriction is for.


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

I am not taking the restriction of level 2 and projecting it to layer 3.
I'm talking the possibility of changing restrictions in the future.


I want to know the reason why non-preservation of scalar identity is
allowed in the spec. As I wrote, I do not see any practical use cases
in which applications or libraries can make use of the part of the spec
for some valuable purpose. You said it allows a schema-blind tool to
load tag-unresolved scalars into native scalar variables and put them
into native collection variables. Will it be really allowed? AFAIU,
such a tool can never write back the data tree into a YAML document
safely, as I wrote in the previous post. Then, what can be the task of
the tools? Do we really have to put much importance on such use cases?
These are my questions. Note that I of course allow libraries to discard
identities of real scalars such as !!str and !!int
_after complete tag resolution_.

Thank you for your patience.
Osamu Takeuchi




On 2016/03/09 3:40, Oren Ben-Kiki wrote:
> 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] <mailto:[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] <mailto:[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://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140