Re: YAML Multi-Layer Spec

You are right. We should have taken a hint from the OSI and defined the
layers much more strongly. Off the top of my head: layer 1 - physical
(encoding etc.), layer 2 - presentation (grammar), layer 3 - abstract graph
(data model), layer 4 - concrete (native) data.

E.g., tag resolution works in layer 3. It takes a partial graph (w/o tags)
and fills it up (associates a tag with each node). A resolved graph means
we now know exactly what the concrete type of each node will be, and all
that's left is the act of constructing it.

Something to keep in mind if/when we do another version of the spec. We can
start using the layer terminology in your implementation guide right away.


On Fri, Mar 4, 2016 at 10:40 PM, Ingy dot Net <[email protected]> wrote:

> Since this thread seems to be winding down, I've changed the subject.
> About a year ago I was driving home from a conference where I gave a talk
> on YAML. I had a sort of epiphany where I realized the source of a lot of
> the contentions we had (and still have) around things like duplicate keys,
> key order, equality and such.
>
> YAML processing is stack based: See the diagram in
> https://github.com/ingydotnet/yaml-dev-kit/blob/guide/yaml-loader-guide.pod#readme
>
> A Load operation is:
> (source)->read->(chars)->lex->(tokens)->parse->(events)->compose->(graph)->construct->(native)
>
> The YAML Spec talks about all of these things, but primarily it defines
> precisely a token grammar.
>
> My big realization was that the spec needs to "spec" each layer and
> transform. They are each distinct, and need to be defined and reasoned
> about distinctly.
>
> For instance, it is not good enough to say "On input, a YAML processor
> must support the UTF-8 and UTF-16 character encodings. For JSON
> compatibility, the UTF-32 encodings must also be supported."
>
> You would want to state this in the "Reader" section.
>
> Statements about Key Order and Duplicate Keys can't be made about "YAML"
> but about YAML processing at the graph layer. At the parser level there can
> be no concept of key order or duplication. In a streaming processor, it is
> almost certain that key order will be preserved.
>
> ...
>
> I don't think we need to be alarmed in any way. I think the spec is fine
> for what it is. I am hoping to capture all of this in a more accessible
> form in the dev kit <https://github.com/ingydotnet/yaml-dev-kit>. Also
> with tests that force the issues. I think that will be much easier to
> reason about than the spec.
>
> On Fri, Mar 4, 2016 at 9:04 AM, Oren Ben-Kiki <[email protected]> wrote:
>
>>
>>
>> On Fri, Mar 4, 2016 at 7:01 PM, Osamu TAKEUCHI <[email protected]> wrote:
>>
>>> Let me confirm one point. Does this allow identity-based
>>> comparison of mapping nodes with some specific tags?
>>
>>
>> Not sure what you mean. In YAML each mapping node has its own identity
>> which is different from all other nodes. The only way for two mapping nodes
>> to have the same identity is via an alias (anchor and reference).
>>
>>
>>> > But that issue doesn't seem to be the one raised here;
>>> >the problem seems to be with the "early duplicates detection".
>>> >Which, again, is explicitly not required by the spec.
>>> >So I'm not certain what the actual problem is with the current
>>> >rules. Is this a case of the perceived rules being different
>>> >from the actual rules in the spec?
>>>
>>> If you don't see any problem to relax the equality detection
>>> as above, neither do I.
>>>
>>
>> There's no need to "relax" it, it is "relaxed" already.
>>
>> Oren.
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Yaml-core mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/yaml-core
>>
>>
>

------------------------------------------------------------------------------

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