Fix file format documentation inconsistency against implementation - #438
Fix file format documentation inconsistency against implementation#438jassielof wants to merge 12 commits into
Conversation
…nsensitive matching of entry types.
…insensitive matching of roles.
…typst#432) Also added local tests, with a new test mode for links. --------- Co-authored-by: PgBiel <9021226+PgBiel@users.noreply.github.com>
|
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 For the rest, I feel it's fine, maybe? 😭 |
| "cast-member" => Ok(PersonRole::CastMember), | ||
| "composer" => Ok(PersonRole::Composer), | ||
| "producer" => Ok(PersonRole::Producer), | ||
| "executive-producer" => Ok(PersonRole::ExecutiveProducer), |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
thanks ill try to implement it once i get a response from the team
There was a problem hiding this comment.
I agree with @MultisampledNight. Adding heck seems like a good idea.
Fixes related to #346:
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?