Contributor Data Explanation

so the json datafile contains a slew of keys. the values will depend on a specific user’s implementation of this theme.

I have a set of contributor-provided datafiles for my hugo staticsite. these contributor data files are used by hugo partials to generate our website. I am trying to create a json schema from them so that we can write some hugo partials to process the data with a clear expectation of what data we should expect to ingest. the attributes that aren’t specifically listed in the draft-2020-12 spec should be treated as custom properties.

I am going to provide you:

a representative sample of contributor datafiles.. please remember that these samples are sufficient to exemplify the variance we are expected to tolerate, but do not represet the entire set of valid names/values/etc so do not hard-code specific names of, for example, social media sites, language names, filenames, etc.
the jsonschema 2020-12 specification files.
the jsonschema file I’ve mostly gotten put together.

I would like you to:

review the jsonschema draft 2020-12 spec files, so that you can have the most truthy data possible.
review my work-in-progress schema file.
review my contributor datafiles so that you understand how the data is presented.

then, I would like you to ask any clarifying questions you have. Once you have an understanding of any relevant uncertainties, I’d like you to make adjustments to my jsonschema file, and continue iterating on it until you have a schema that all the datafiles I provide you are considered valid compared against it.

Assuming the work I have outlined makes sense, and you don’t have any immediate questions, please tell me the order in which you’d like me to provide you with the:

jsonschema 2020-12 draft spec files
the work in progress contributor schema
the contributor datafiles

the date for the optional field join_date may be MM/YY YYYY or a MM/DD/YYYY format…

the content of this key is displayed within a section of the contributor’s profile page.

it’s not out of the question for them to populate it with just a string, or attempt to add some minor html formatting. Complex HTML isn’t supported, but I don’t want to unnecessarially constrain the contributor’s flexibility for adjusting the presentation of their content here.

byline_title bio headline and the different variants of the contributor’s name:

fullname (or) firstname lastname and optional middlename may all either be a string, or an array of languagename and language-scoped-value pairs.
in my datafiles, I only support the languages en and brk with a default fallback. but any string is a valid language name.

The Optional social array contains a set of objects relevant to facilitating someone connecting with that contribtor via that medium.

Each object is a set of Key and value pairs.
- The Key is generally expected to match an icon in the assets/icons folder of the project. As such, it’s generally expected that the key name will align with the common name of the platform in question.
- The Value is generally expected to be a URI which links to the contributor’s profile, page, section, entity, or showcase or entrypoint as relevant to that platform. Corespondingly, the URI Schema is fairly loose here.

Since the display of social links is optional, The key’s presence is optional.

The key may be present, and populated with:
- An empty array: []
- An array with an empty object: [{}]

If values ARE provided, they should be:

Provided as an object containing:
- Key string Representing the name of the social media site, platform, or contact medium. (for example, ‘Phone’ is a valid key. however the ‘uri’ will look nothing like a web url)
- Value string URI a URL/uri representing that contributor’s profile/page/whatever on that platform.

Config Object #

the config property contains a slew of attributes relevant to the way that contributor would like pages attributed to them look. this includes the optional inclusion of a background svg pattern they would like visible on their profile and info card, and the colors and attribute properties relevant to that.
- it also includes their image and the filepath to it, relative to the assets folder in the hugo project.

it also contains optional attributes relevant to different parts of the site. such as ‘profile’ on the profile part of the site, we enumerate content authoried by that contributor, and the ’excluded_content_types’ key contains a list of hugo content types that are not to be enumerated in that context.

Not every user of the theme will use internationalization. and not every contributor to the sites that DO use internationalization will provide full distinct values for every supported language..

(I think this answers Q’s 1 and 2)

since we do not know all the different mediums that a contributor may wish to provide as ways to engage with them, we are simply creating it as an enumeration of “social-media-construct-name” and “contributor-specific-uri-for-that-social-media-construct”.

the pattern_names property allows a contributor to specify which of about 80 different svg background patterns I have created to use as their page background.. additionally they may specify the fill, stroke, and stop colors, the fill, and stroke opacity, and the stroke width.
the color value may either be a hexcolor, or a tailwindcss ‘colorname-(([1-9]00)|9?50)$’ color value.

Does that answer your questions? Are you ready for the datafiles?

a contributor may provide numerous variations of their name. for example

fullname: ‘john doe’

middlename: [ {‘foolanguage’: ‘I-use-my-middlename-in-foolanguage’}]

or they could provide:

firstname: ‘john’

lastname: ‘doe’

or they could provide:

firstname: ‘billy’

lastname: [{‘default’: ‘joel’},{’texan’: ’the kid’}]

… see why it’s a bit complex?

yes, any property which accepts a language-enriched array of language-specific values must also accept a long, potentially multi-line string.
yes. concur.
the social property is optional. as such, there are none that are required. The social key may be absent, or it may contain an empty array, or an array with an empty object. each of these are potential valid edge-cases.
if you mean the underscore_separator versus the capitalizationDelineation, it’s an unfortunate requirement. in another part of the parsing functionality there is a component which accepts neither underscores, nor hyphens. and hugo lowercases any primary keys when turning them into variables… ah the fun complexities and corners we back ourselves into, no?
I am pretty sure that every instance of the ‘image’ key in these datafiles has a value that references a relative filepath.

The implementation DOES support a full URI should one provide one, for example, referencing an externally sourced resource.. however that isn’t a pattern I want to loudly encourage as it can introduce build-time dependency on connectivity which I consider an antipattern, however some users explicitly wish this functionality to work.

yes. see #4.
yes. Concur.

Thank you for being so thorough.

you are by far the most attentive, and detail oriented assistant I have had… I beleve you have the ability to ACTUALLY HELP ME as opposed to the many previous assistants I have worked with, which have consistently had a very hard time even getting to this point… you are doing amazingly well. I really wish to express my excitement that we might actually be able to accomplish this.

I have been trying to get this finished for … days now… and every assistant before you has utterly failed…. so… thank you for giving me hope.

Are you ready for the draft-2020-12 specifcation files now? or do you have other questions I may answer for you?

Social Media/ The Social key: #

Config Object #