Re: Next YAML: drop equality definition

Yes, I see layer 0 as being the "physical layer" - bytes in the file, which
need to be converted to code points so that layer 1, the "presentation
layer" can parse/tokenize/scan it. This is consistent with section 3 of the
spec.

On Mon, Mar 7, 2016 at 9:33 PM, Ingy dot Net <[email protected]> wrote:

> Thanks Oren,
>
> I'll try to make all of this clear in the YAML Developers Guide. I can
> start by making a document that declares the layers and what properties
> apply and such. Then we can have more precise and targeted arguments. :)
>
> My main addition is that the reader/writer transforms between your layer 0
> and 1 are responsible for transforming between a unicode encoding and a
> stream of unicode code point integers. Do you agree?
>
> Ingy
>
> On Mon, Mar 7, 2016 at 10:54 AM, Oren Ben-Kiki <[email protected]> wrote:
>
>> This has been a long thread...
>>
>> The way I see it: The spec is what it is :-)
>>
>> Using the layered approach to describe YAML processing, then:
>>
>> Layer 0 is the text file (Unicode encoding etc.). It doesn't do anything.
>>
>> Layer 1 is the parser/scanner/grammer/etc. It doesn't do duplicate key
>> detection. It does provide key order. It provides indentation levels, and
>> the way strings are wrapped in lines, and how characters are quoted, and
>> lots of other "presentation" details. It can be streaming. YamlReference is
>> an example.
>>
>> Layer 2 is building an abstract node graph (with either some or all of
>> the nodes having resolved tags). It _need not_ preserve key order. It _need
>> not_ preserve identity of scalars. It _may_ do duplicate key detection, but
>> if it does it _must_ do so in a way that ensures "no false positives", that
>> is, it may _only_ flag keys as duplicate if the application _must_ consider
>> them equal, given the YAML data model (thanks to Osamu for finding a gap in
>> the definition of this data model).
>>
>> Layer 3 is the application native data structures. They _must not_ depend
>> on scalar identity. They _must not_ depend on key order in a mapping. They
>> _must not_ depend on duplicate keys in a mapping. You can have key order
>> and duplicate keys in an !!omap or something like that.
>>
>> A concrete system can work at level 0 only (e.g., re-encode a YAML file
>> from utf-8 to utf-32be). Or level 0/1 only (e.g., a YAML pretty-printer).
>> Or level 0/1/2 only (e.g., a ypath tool for extracting specific fragments
>> from a document). Or level /0/1/2/3 (a full application). All are valid.
>> Each one uses a different (related) data model.
>>
>> Much of the confusion in this very long thread is due to people applying
>> the restrictions or data model of a level X to another level Y where they
>> do not apply. Also, confusing between what is _allowed_ and what is
>> _required_ in each level.
>>
>> The above rules allow _control_ over the interoperability of YAML data
>> between systems. Note - "control", not "guarantee". Nothing can "guarantee"
>> interoperability between the native data types of completely unrelated
>> platforms.
>>
>> The rules also try to minimize the "surprise" people may feel when
>> learning on how the application actually interprets the data.
>>
>> Sometimes this means that less-common data needs to be serialized with a
>> bit more syntax (e.g., !!omap notation vs. !!map notation). Note the fact
>> we _require_ the use of a less-streamlined syntax (1) does not _prevent_ us
>> from being able to serialize "anything at all" into YAML and (2) does not
>> necessarily reduce legibility - in fact, it arguably increases.
>>
>> Now, you can break any of the above rules, with the understanding that by
>> doing so you are stepping outside of what YAML provides. In this case your
>> system may produce unexpected results if valid YAML processors are applied
>> to the data, and will "surprise" people who expect YAML behavior. So, while
>> we can't prevent people from doing whatever they want - this is a free
>> universe - we can require that people doing such such things will not say
>> "this is a valid YAML system".
>>
>> BTW: The reason that tags can't apply to different kinds of nodes is due
>> to the identity issue. Collection identity is guaranteed by YAML. Scalar
>> identity is not. Applying the same tag to both raises some sticky issues.
>> That said, we may be able to relax this by using careful wording
>> (especially given the gap Osamu has found). I'm not certain it is a problem
>> in practice, though.
>>
>> So... "it is what it is". I hope the above helps explain why.
>>
>> Oren.
>>
>>
>> ------------------------------------------------------------------------------
>> 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