Clash of UUIDs between different elements

[strogonoff]

I’m working on rendering this as a collection with a Firelight GUI. Rendering a collection implies a global identifier scope (making possible a reference to a particular document part from anywhere in the collection).

However, after building the collection using bundle exec metanorma site generate --agree-to-terms, I see this (from two different files):

• It appears that Metanorma presentation XML treats identifier scope as per-document in case of this collection. I did not expect this, because it was discussed in context of 10303 that references across the collection are possible.

  However, I can understand that this may be a different case from 10303. Perhaps unlike 10303 this collection is not a “true” Metanorma collection but some other kind of collection (I forgot the precise term): https://github.com/CalConnect/cc-admin-documents/blob/main/metanorma.yml. If so, maybe it’s not Metanorma’s problem. I’ll check whether there is a clash with a “true” collection if I can find one to easily try.

• It appears that Metanorma generates the same UUID for an element with different contents. In the above screenshot, the elements have identical children, but they have 1) different attributes and 2) different tag names. Those qualify as semantically different contents (a clause#foobar is a very different thing from note#foobar). If UUID is meant to vary on content, then it’s not doing its job.

  (There is a larger problem here, which is that two elements even with identical children, attributes, and tag names, would mean different things if they appear in different place of the document, because unlike a normalized resource graph any part of a document implicitly derives its meaning from its relationships with parents and siblings. This can be debated depending on what was the purpose of content-derived UUIDs, which I do not know.)

This should probably be filed somewhere in some project under metanorma, but I don’t know where. Feel free to transfer appropriately.

[ronaldtse]

A "Metanorma Collection" has namespaced IDs unique per collection. A "Metanorma Site" does not have namespaced IDs.

[ronaldtse]

It appears that Metanorma generates the same UUID for an element with different contents. In the above screenshot, the elements have identical children, but they have 1) different attributes and 2) different tag names. Those qualify as semantically different contents (a clause#foobar is a very different thing from note#foobar). If UUID is meant to vary on content, then it’s not doing its job.

This particular example you're using is the Foreword. All (most) CalConnect documents share the same Foreword, hence the content is identical. The ID is created based on "content" in the element, which is identical. This particular ID does not consider the container itself.

[strogonoff]

The ID is created based on "content" in the element, which is identical.

It is not identical content. Tag name and attributes constitue content along with child elements.

This particular ID does not consider the container itself.

That is likely a bug or wrong specification. An attribute is part of the content. Tag name is content, too (<clause><x></clause> is very different from <xref><x></xref> for example). The ID identifies the container element with its descendants, not just its descendants.

[ronaldtse]

@strogonoff perhaps you can find the original ticket that described the ID generation algorithm to see the rationale. I don't quite remember on top of my head why this was implement this way. Actually instead of asking you to do it, let me do a search.

[strogonoff]

Thank you, it could shed some light, but I suspect in the end it will just show that element identity was simply incorrectly defined. The algorithm may be correct, but requirements not.

[ronaldtse]

This is the ticket. metanorma/metanorma-standoc#24

Seems that we did not talk about the element/attributes back then. This is a bug.

The criteria for the ID was:

• content
• position (relative to root)

[strogonoff]

I see. I think an important part was minimizing diff. Let me consider it in that context.

[ronaldtse]

@strogonoff at first glance I don't see how it minimizes diff because we're not supposed to change elements...?

[strogonoff]

@ronaldtse “Minimizing diff” was the goal behind the ticket and it is a very different goal than what I have in mind (“identifying atoms of content”). Both need stable identifiers but requirements are different, something can work for the former but not for the latter.

Identity of a piece of content is not an easy question by any means, and in context of a document it is even less straightforward compared to, say, a graph of relations.

[strogonoff]

It is tempting in web context to be forgiving about identifying atoms (to keep links working after changes) but the real solution to keeping links working after changes is to track evolution and supply usable redirects