What's wrong
For a key that has neither an exact nor a known mapping, NameStandardizer.FindStandardPropertyMatch (Frontmatter/NameStandardizer.cs, the partial-match loop around line 127) accepts any standard property whose normalized name is a substring of the key (normalizedKey.Contains(normalizedStandard)). It then renames the key to that property. This happens even when nothing else claims the name. StandardOrder.PropertyNames includes author, version, image, slug, url, date and others, so many ordinary compound keys get renamed to a field that means something else.
Repro (default overload: Standard naming, Conservative merge)
Frontmatter.CombineFrontmatter("---\ntitle: Post\nauthor_email: bob@example.com\nprevious_version: 1.2\n---\nbody\n");Observed:
title: Post
author: bob@example.com
version: 1.2
Expected: author_email and previous_version are kept as they are.
Under FrontmatterMergeStrategy.None, these renames also happen:
image_credit: Jane Doe becomes image: Jane Doeurl_slug_notes: see wiki becomes slug: see wiki
Why it matters
The document now claims its author is an email address and that the current version is the previous one. Any static-site generator or tool that reads author, version or image gets the wrong value. Nothing warns the user, and the original key is gone. This is not #136: that issue is two keys colliding on one name. Here a single key is renamed to a field with a different meaning.
Suggested fix / acceptance criteria
The containment heuristic is intentional: tests expect url to match canonical_url, and #128 added a minimum length. It needs to tell apart a key that decorates a standard name from one that qualifies it. Options:
- Only allow the
standard ⊂ key direction when the leftover words are known decoration, meaning the prefix and suffix lists PropertyNameNormalizer already strips. Otherwise keep the key as it is.
- Or require the word sets from
NormalizeToWords to match, allowing for a plural.
Acceptance: author_email, previous_version and image_credit pass through CombineFrontmatter unchanged. The existing containment tests, such as MergeSimilarProperties_WithContainmentSimilarity_MapsCorrectly, still pass or are updated on purpose.
What's wrong
For a key that has neither an exact nor a known mapping,
NameStandardizer.FindStandardPropertyMatch(Frontmatter/NameStandardizer.cs, the partial-match loop around line 127) accepts any standard property whose normalized name is a substring of the key (normalizedKey.Contains(normalizedStandard)). It then renames the key to that property. This happens even when nothing else claims the name.StandardOrder.PropertyNamesincludesauthor,version,image,slug,url,dateand others, so many ordinary compound keys get renamed to a field that means something else.Repro (default overload: Standard naming, Conservative merge)
Observed:
Expected:
author_emailandprevious_versionare kept as they are.Under
FrontmatterMergeStrategy.None, these renames also happen:image_credit: Jane Doebecomesimage: Jane Doeurl_slug_notes: see wikibecomesslug: see wikiWhy it matters
The document now claims its author is an email address and that the current version is the previous one. Any static-site generator or tool that reads
author,versionorimagegets the wrong value. Nothing warns the user, and the original key is gone. This is not #136: that issue is two keys colliding on one name. Here a single key is renamed to a field with a different meaning.Suggested fix / acceptance criteria
The containment heuristic is intentional: tests expect
urlto matchcanonical_url, and #128 added a minimum length. It needs to tell apart a key that decorates a standard name from one that qualifies it. Options:standard ⊂ keydirection when the leftover words are known decoration, meaning the prefix and suffix listsPropertyNameNormalizeralready strips. Otherwise keep the key as it is.NormalizeToWordsto match, allowing for a plural.Acceptance:
author_email,previous_versionandimage_creditpass throughCombineFrontmatterunchanged. The existing containment tests, such asMergeSimilarProperties_WithContainmentSimilarity_MapsCorrectly, still pass or are updated on purpose.