Skip to content

Fix file format documentation inconsistency against implementation - #438

Open
jassielof wants to merge 12 commits into
typst:mainfrom
jassielof:docs-inconsistency
Open

Fix file format documentation inconsistency against implementation#438
jassielof wants to merge 12 commits into
typst:mainfrom
jassielof:docs-inconsistency

Conversation

@jassielof

Copy link
Copy Markdown

Fixes related to #346:

  • Makes both the entry and affiliated role types fully case insensitive.
  • The file format now explains that the affiliated can be either a single object or a list.
  • Removed outdated sentence case element from the basic test.

For the affiliated I initially wanted to not allow single objects, but well, it feels more convenient than having a single element list for it.

For the timestamps, the validation or enforcement regarding the format wasn't valid with the overflow, not sure if this was intended or well 😞.

Also, if might be relevant to fix some examples in #36, with clarification or just commenting on the issue?

@jassielof

jassielof commented Dec 29, 2025

Copy link
Copy Markdown
Author

Actually, for the sake of simplicity, I feel that the entire thing of entry and role types shouldn't be much of fully case insensitive now 😔, mainly because of the JSON Schema, at least with the draft 7, it doesn't support case insensitive enumeration, nor case insensitivity in regular expressions. And more up to date drafts/specifications aren't widely or generally supported yet.

For the role types it's easier to make it into the schema with an enumeration, but with the entry types it gets different since one must retype both "article" and "Article" in the enumeration, or well if easier with regular expression just [Aa]rticle|... but then it gives a bit of bad feedback for the completions, in editors as it throws that it doesn't match the whole regular expression, compared to a nice list of accepted values. So, for the entry type at least would probably correspond removing the alias? But yeah, breaking changes 😞.

For the rest, I feel it's fine, maybe? 😭

@MultisampledNight MultisampledNight left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Highly appreciated! ^^

Comment thread src/types/persons.rs
Comment on lines +122 to +125
"cast-member" => Ok(PersonRole::CastMember),
"composer" => Ok(PersonRole::Composer),
"producer" => Ok(PersonRole::Producer),
"executive-producer" => Ok(PersonRole::ExecutiveProducer),

@MultisampledNight MultisampledNight Apr 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't cover CastMember or ExecutiveProducer as it's still in file-format.md (https://github.com/typst/hayagriva/blob/a137441413a5907c15ced44d1502dfb9fa1a3014/docs/file-format.md#affiliated).

@MultisampledNight MultisampledNight Apr 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could depend on heck for the conversion (instead of .to_lowercase, .to_kebab_case) (since it's in our dep tree already it wouldn't impact compile time much)

 = cargo tree -i heck
heck v0.5.0
└── strum_macros v0.27.2 (proc-macro)
    └── strum v0.27.2
        └── biblatex v0.11.0
            └── hayagriva v0.9.1 (/home/user/c/d0/software/document/bibliography/hayagriva)
[dev-dependencies]
└── hayagriva v0.9.1 (/home/user/c/d0/software/document/bibliography/hayagriva)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks ill try to implement it once i get a response from the team

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @MultisampledNight. Adding heck seems like a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants