Subject: [Cellar] EBML Element Parenting

From: Steve Lhomme <[email-masked]>
Date: Sun, 31 Jul 2016 17:41:21 +0200

As we're moving towards splitting the Matroska specs in many smaller
documents, putting not essential things in a document it becomes more
important to define things differently than the "level" element we
currently rely on. It makes it very difficult to define a single
element without having to copy all its parents to explain where it
should go in the EBML format.

I think we should set the name of the parent(s) explicitely to avoid
that confusion. We will also not rely anymore on the order in which
elements are defined in the specs.

I did a pull request with this addition:
https://github.com/Matroska-Org/ebml-specification/pull/83

This change will probably mean many paragraphs need to be rewritten to
rely less on the level system.

I will do the pull request for Matroska as well once it's settled.

-- 
Steve Lhomme
Matroska association Chairman

---

From: Ashley Blewer <[email-masked]>
Date: Sun, 31 Jul 2016 11:46:07 -0400

I agree with this -- better to be explicit rather than implicit.

Is there any instance in EBML/Matroska in which a 1:1 parent-child relation
would not work, such as "Parent can be A or B, but not C-Z" that would make
this a challenge to implement as you've laid out in the pull request?

Ashley

On Sun, Jul 31, 2016 at 11:41 AM, Steve Lhomme <[email-masked]> wrote:

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 31 Jul 2016 17:50:32 +0200

> this a challenge to implement as you've laid out in the pull request?

Not really. The only tricky cases are for nested elements, Void and CRC32.

Nested elements can either have a specific parent or be their own
parent. Example element XYZ can be a child of ABC or another XYZ.
That's why it's important to define nested elements at the same time.

Void and CRC32 are not nested but they don't have a specific parent.
They can be anywhere.

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 31 Jul 2016 18:11:31 +0200

> That's why it's important to define nested elements at the same time.

My bad. What I call nested is called recursive and is already defined.
It's based on levels though and would probably benefit from an
explicit parent too.