Example IDs (data/ext/..) conflicts with new example IDs in data/examples.txt

Open
#3,465 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Domain
build-system, data

Research direction

Start by comparing the IDs in data/examples.txt with the example files under data/ext/bib and data/ext/health-lifesci. Then inspect the build or validation step that reports duplicate globally registered IDs. Done means the chosen ID organization no longer causes conflicts while preserving a clear sequence for future additions.

Written by the indexing model from the issue text.

Description

no-issue-activity

What

The example IDs are globally registered, thus creating conflicts with newly added example IDs in data/examples.txt. This conflict makes the build fail and abort the process. Thus it's not possible to build.

Why

The data/examples.txt has a sequential ID structure and in order to keep it organized, all IDs need to be documented there and not spread out between data/examples.txt and the examples in data/ext/bib, data/ext/health-lifesci, etc.

Further, this doesn't make it easy to track the next ID to be used.

How

Possible solutions:
  • Update the example IDs to a number that's far from what's in production. Example: #eg-99999 Therefore, contributors can add IDs sequentially without interfering with the examples.
  • Not update the example IDs and continue the sequence from the last ID found in data/ext/bib, data/ext/health-lifesci, etc. -- This will break the sequence in data/examples.txt and make it harder to track IDs.

I can open a PR, but wanted to make sure that I'm not missing a detail or if there's a consensus to fix this.

Dominant language
HTML
Stars
6.3k
Forks
962
Avg merge
18h 7m
Merged PRs (30d)
9

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from schemaorg/schemaorg

All issues in schemaorg/schemaorg

Similar issues

More Build System issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.