Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to use latest glossarist gem #31

Open
ronaldtse opened this issue Jan 2, 2025 · 4 comments · May be fixed by #32
Open

Upgrade to use latest glossarist gem #31

ronaldtse opened this issue Jan 2, 2025 · 4 comments · May be fixed by #32
Assignees
Labels
enhancement New feature or request

Comments

@ronaldtse
Copy link
Member

glossarist/glossarist-ruby#107 has been released and is now vastly different from the original.

We need to update this gem to work with the updated glossarist.

@ronaldtse ronaldtse added the enhancement New feature or request label Jan 2, 2025
@github-project-automation github-project-automation bot moved this to 🆕 New in Geolexica Jan 2, 2025
@HassanAkbar
Copy link
Member

@ronaldtse I was working on this issue and came across a scenario where the specs were failing due to a difference in the format of DateTime in the parsed JSON of a sample concept and the DateTime after serializing the concept object, here is the sample date:

JSON data:
{ "date": "2007-09-01T00:00:00+05:00" }

From Glossarist
{ "date": "2007-09-01 00:00:00+0500" } => iso8601

As you can see in the example above, Glossarist returns the date in iso8601 format but in JSON, it is in a different format
So for now to make the specs pass, I have changed the format to iso8601 in the JSON file.

Please let me know if this is the correct approach or if we should change the format from glossarist to match the format in JSON

@HassanAkbar
Copy link
Member

@ronaldtse I wanted to ask what will happen to the other glossaries once we migrate jekyll-geolexica to use the latest glossarist since they are still on v1.
Some of the glossaries are osgeo.geolexica.org and isotc204-glossary. These still use v1 and site generation will break if we migrate jekyll-geolexica to the latest glossarist.
We should migrate these repos to use v2 first before migrating jekyll-geolexica to latest glossarist since it supports v2 only.
Please let me know what do you suggest here?

@HassanAkbar HassanAkbar linked a pull request Jan 16, 2025 that will close this issue
@ronaldtse
Copy link
Member Author

@ronaldtse I was working on this issue and came across a scenario where the specs were failing due to a difference in the format of DateTime in the parsed JSON of a sample concept and the DateTime after serializing the concept object, here is the sample date:

JSON data:
{ "date": "2007-09-01T00:00:00+05:00" }

From Glossarist
{ "date": "2007-09-01 00:00:00+0500" } => iso8601

As you can see in the example above, Glossarist returns the date in iso8601 format but in JSON, it is in a different format So for now to make the specs pass, I have changed the format to iso8601 in the JSON file.

This is so weird, because the typical iso8601 format is YYYY-MM-DDTHH:MM:SS{OFFSET}. We should make lutaml-model default to the format of "2007-09-01T00:00:00+05:00". The one with the space is not preferred.

@ronaldtse
Copy link
Member Author

@ronaldtse I wanted to ask what will happen to the other glossaries once we migrate jekyll-geolexica to use the latest glossarist since they are still on v1. Some of the glossaries are osgeo.geolexica.org and isotc204-glossary. These still use v1 and site generation will break if we migrate jekyll-geolexica to the latest glossarist. We should migrate these repos to use v2 first before migrating jekyll-geolexica to latest glossarist since it supports v2 only. Please let me know what do you suggest here?

We should migrate all these datasets to the latest formats and re-deploy them using the latest versions. The order doesn't quite matter. We do have an issue with glossarist/glossarist-ruby#116 where we don't have a good specification on the rich-text contents in the "definition" sections, which we need to resolve finally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🔖 Ready
Development

Successfully merging a pull request may close this issue.

2 participants