Are implementations expected to preserve the order of nodes in the document root? #154
-
|
"Children should be used if an order-sensitive key/value data structure must be represented in KDL," doesn't necessarily mean that nodes are order sensitive in the document root, so... /- "Explicitly Unordered"
- answer=42 \
author="Douglas Adams" \
work="The Hitchhiker's Guide to the Galaxy"
/- "Explicitly Ordered"
- { answer 42
author "Douglas Adams"
work "The Hitchhiker's Guide to the Galaxy"
}
/- "Explicitly a Different Order"
- { author "Douglas Adams"
work "The Hitchhiker's Guide to the Galaxy"
answer 42
}
/- "What about this..."
answer 42
author "Douglas Adams"
work "The Hitchhiker's Guide to the Galaxy"
/- "And this..."
author "Douglas Adams"
work "The Hitchhiker's Guide to the Galaxy"
answer 42
Are the last two equivalent? If the node order in the document root isn't relevant, that allows implementations to naively rely on the object and table handling native to their programming environment even when these don't guarantee that the node order will be preserved, e.g. in Lua, the order of keys in tables will generally be preserved, but it isn't guaranteed when there are deletions and insertions. If node order in the root is not preserved, that has implications when designing parsers that don't consume the entire document before they begin producing results The documented behavior of Lua means that my implementation should preserve node order in both root and children when a KDL document is round tripped, assuming that there are either no deletions (insertions will be made at the end of the document) or that there are no insertions after a deletion occurs (deletion will not change the order of remaining nodes, but subsequent insertions are made to the first available position). I'll obviously need to repack children on occasion, but it would be nice to avoid repacking the document root Also, this question would likely be answered by a test suit. I don't remember seeing one, but that doesn't mean it doesn't exist... |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
It depends on your use case, honestly. At the KDL level itself, those last two are two completely different documents, because child nodes are ordered. But it your parser is putting things into a hash table in a use case where users don't actually care about order, that's actually fine? So I guess the answer is "it depends on the use case" |
Beta Was this translation helpful? Give feedback.
-
|
Like to clarify: if your intention is to round-trip a document, you must ABSOLUTELY preserve this order. Same if your parser converts children to lists instead of key value pairs. Oh and as far as a test suite goes: we have one in this repo! I'd link it but I'm on mobile right now. It's over there tho |
Beta Was this translation helpful? Give feedback.
-
|
Don't worry about searching up the link for the test suite. Since I know it's there, I'll find it Yes, hash tables are the underlying implementation. There's an index that will preserve the order in a naive implementation, but I'll need to use schemas (creating a temporary one if necessary) if deleting a node, inserting a different node, then re-inserting the deleted node, and deleting the inserted node should reproduce the original document. My opinion is that it should, and I'm excited because it opens up some possibilities when parsing larger documents |
Beta Was this translation helpful? Give feedback.
-
|
And I found the test cases... It's a peculiarity of my sensory processing that I do not remember seeing things that I wasn't looking for |
Beta Was this translation helpful? Give feedback.
It depends on your use case, honestly.
At the KDL level itself, those last two are two completely different documents, because child nodes are ordered.
But it your parser is putting things into a hash table in a use case where users don't actually care about order, that's actually fine?
So I guess the answer is "it depends on the use case"