Re: Next YAML: drop equality definition

On 3/11/16, Osamu TAKEUCHI <[email protected]> wrote:
> Zenaan,
>
> Thank you for your comment.
> It let me know that I should have shown how I use custom
> tags and custom tag resolutions in my apps.
>
> Indeed, the C# library I developed uses the class
> definitions as the custom schema.
>
> Namely, if a YAML document
>
>    !MyClass { a: true, b: true }
>
> is given to the library and MyClass is defined as
>
>    class MyClass
>    {
>      public boolean a { get; set; }
>      public string b { get; set; }
>    }
...
> This is how the schema works in my apps.
>
> Do you think my library is exceptional?

Sounds normal layer 4 library to me. Same as others. I've only ever
used Java YAML, but all 3 worked similarly.

...
>> If a particular YAML "middleware" that I, the man with the editor, am
>> using, let's say a YAML pretty printer, unexpectedly preserves scalar
>> identiy, then I'll tell the dang pretty printer where to go.
>>
>> If I am programming some transactional multi layered software, and
>> some middleware layer needs to work in a particular way (preserving
>> identiy, or not preserving identiy), I'm simply going to make sure the
>> YAML tool I use supports the mode of operation that I require.
>>
>> I think you might be trying to solve a non existent problem?
>
> Besides the identity issue, a YAML document with custom tags
> and custom tag resolutions are already surprising to those
> who has limited knowledge on the schema. Identity preservation
> of scalar node do not make it very much worse.

It's just too theoretical. A "surprised YAML document editor" better
check out the schema for the document s/he is editing!

> And I repeat, even you mistake the need for identity preservation,

It's about "default presumption" - if two nodes, which look the same,
are spelled the same, have the same capitalization and the same
spacing, have different identity without any special schema, that
sounds not intuitive. It's not about the need, it's about
expectations. That's why it is so good that the order of design
priorities for YAML has been set, along with clear definition of
layers of processing. "What is likely user expectation at -this-
layer?" for example.

>>>> 6. YAML is expressive and extensible.
>>>>
>>>> You could argue that not preserving scalar identity
>>>> requiresa morecumbersome expression of some native
>>>> data (e.g. wrappinga scalarin a collection "just
>>>> because" you want to ensure itsidentity ispreserved -
>>>> similarly to having to use an !!omapinstead of the
>>>> cleaner map syntax for PHP dictionaries).
>>>> "Everything" still _can_be expressed, though.
>>
>> This sounds intuitive to me.
>>
>>> If the benefit is larger than the labor, I will accept
>>> the restriction.
>>
>> For starters, your !!not_float example seems artificial to me - like
>> trying to solve a non existing problem. Changing an "intuitive to
>> humans" aspect of the current YAML spec (/ default schema), in order
>> to solve a non real world problem, would be a step backwards for YAML.
>
> I hope the example above explains the problem.

I still don't see a problem. You use tags, at least for the document
root, which means your users are specifying a schema - that's just
fine. YAML supports your usage AFAICT.

Sorry, I really have been known to be slow, but I'm not seeing your
usage of YAML violating the specification. Use any "schema" tags that
are suitable for your application - seems you are doing this
successfully.

>>> For !!omap issue, I am about neutral.
>>> I see it can prevent people unintentionally breaking a
>>> YAML document by swapping the key order. I evaluate this
>>> happens much more easily than someone aliases or unaliases
>>> unexpected nodes.
>>
>> Map and OrderedMap are well defined (mathematically) concepts. YAML
>> supports both, map by default schema, any other type of map by
>> alternate schema/ tags. Any middleware will only ever be employed in a
>> processing pipeline where it makes sense to use that. There is no real
>> world problem that has knocked on the door.
>
> I'm afraid I do not catch your point correctly.
> Do you say people never accidentally swap key orders of
> !!omap if they are familiar with the meaning of the document?
> I almost agree with you then. In that sense I am about neutral.

I remember using the wrong Java map class when "deserializing" a YAML
document, and realising I needed an ordered map type. The "schema" was
implicit/ in my mind (since I wrote the YAML file by hand), so I
changed the type and bingo, all was fine. There is no problem I see
with the YAML spec - once I realised my misunderstanding I said to
myself "oh, that makes sense" and the solution to my need was
immediately self evident (now my Java bean elements (fields, methods
etc) are laid out in the same sequence in the bean/ class file, as in
the YAML files I type up - it wasn't even a functional issue, just a
'visual expectation' issue).

...
>>>> One of the reason we explicitly listed the goals,
>>>> _in order_,was to break ties when different goals
>>>> pushed us in differentdirections. Order the goals
>>>> differently, and you'll get adifferent spec. I think
>>>> you would end up with JSON if youorderedthem in a
>>>> different way. Or even, god help us, XML ;-)
>>>
>>> I strongly agree with this statement and seemingly
>>> the order itself is nice, too. But as I commented on
>>> the first item, the order can not be super strict.
>>
>> Au contraire! I support a "super strict" order, so YAML design
>> decisions are consistent over the years. This has been the case - one
>> of the really nice things about YAML. Now we have "-layers-, onion
>> boy" (with apologies to Shrek), so I'm even happier. Design
>> consistency in YAML is truly awesome. And the order of design
>> priorities is very appealing to me personally. Did I mention I like
>> YAML?
>
> Ok then, drop custom tags and custom tag resolutions
> from the spec completely. Use only standard tags.
> Use only standard schema.This will make YAML documents
> more readable. Does It reduce the functionality of YAML?
> Don't care. Functionality is given a lower priority.
> If readability matters, forget about anything else.
>
> If you say GO SUPER STRICT!, nobody can oppose this
> decision.

No, that's not what I say - it's about "choose priorities, only
override them if a convincing argument is put" - I thought I said that
somewhere.

> I'm afraid you may indeed decide restricting the use
> of custom tags and custom tag resolution. I understand
> it can be one way to go, but...

Of course not. As I also said, it's currently about the only way I use
YAML (when I have time to tinker with programming), although my most
recent experiment has been how to do what I wanted to do, without
tags.

Layers. The answer is clear. Schema-dependent YAML end points, cannot
use a schema blind YAML middleware - this is not a problem anyone has
ever said they have, and also is not a problem at all that I can see
in my mind. I grant I may not see things very clearly though...


>>> Another point is, I feel that most of the YAML documents
>>> in your mind are those that can be stored in JSON but
>>> those in my mind are not always. YAML documents with
>>> full of custom tags are not easily stored in JSON.
>>
>> I disagree. Every tag can be transformed into a two element list,
>> where the first element is the tag, and the second element is the node
>> content that was tagged. Or instead of a two element list, think a two
>> element map, e.g.:
>> -
>>    tag: omap
>>    content:
>>      blah
>>      blah
>
> It may depend on personal standards.
> I do not see this easy.

If your library supports lists and maps, but not tags, then this is
your option. I'm imagining a limited language and someone trying to
implement a YAML library under severe restrictions. "It is easy"
referred to how to get around a language limitation, and that YAML
syntax supports more than one work around, trivially. Frankly, a map,
is simpler than a map and tags. It just means that construction must
be completed by the end user application - but the whole point of this
example was to demonstrate a simple workaround for a theoretical
problem (how to represent tags in JSON), so I think I am way off topic
at this point.

...
> I hope I have convinced you guys that at least some of
> the benefits of allowing non-preservation of scalars with
> custom tags are kind of imagination. Letting tags to
> choose preservation of node identity will hurt you very
> little if any. Letting tags to choose the way of evaluating
> equality, too. Especially, if you have no middlewares that
> understands custom schema around you, they have almost
> nothing to do with you, anyway.

This is a bit beyond my ability to comment properly sorry - back over
to you library implementer people :)

Regards,
Zenaan

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