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

Source of BSP to be confirmed #87

Closed
cmsdroff opened this issue Apr 15, 2022 · 10 comments
Closed

Source of BSP to be confirmed #87

cmsdroff opened this issue Apr 15, 2022 · 10 comments

Comments

@cmsdroff
Copy link
Contributor

cmsdroff commented Apr 15, 2022

From discussion with CEFACT about the work we are doing and specifically this page https://service.unece.org/trade/uncefact/vocabulary/uncefact/

It is acknowledged by all it is in a Draft format release, on enquiry of how we make this Official it will need to go through a publication process and be produced from a UNECE release (twice a year)

It was understood that as we only had the Excel version of BSP available this would be the continued source for the vocab work.

This is not the case, the Excel output was provided following some manipulation work from the outputs and due to the size of BSP maybe missing some points, so this isn't entirely repeatable in an autonomous way.

It's advised that the work of the API Spec project will enable the production of a JSON schema from which the Vocab team would then produce the json-ld vocab and associated output to be published at the above page.

This is not well known within the team and the project has moved forward using the 'source' of the Excel which is all we had available at the project start to adhere to the agreed completion dates.

Raising the issue here to allow tracking and resolution

@cmsdroff
Copy link
Contributor Author

cmsdroff commented Apr 15, 2022

@nissimsan this is a potential blocker to the project timeline, the API Spec team do not as yet have an output available, also the code generation is based upon the Excel BSP 20a release and we need a repeatable way to produce the json-ld without human intervention.

Please consider marking this as a blocker.

@nissimsan
Copy link
Contributor

Making it a blocker to change the source data format which we have with a format which does not yet exist seems like a rather bad idea to me.

Everyone would prefer JSON over Excel, so once a source file is available which is technically superior and produced from a stadardized process, that'll be a strong change request. I don't see how we can action this now, though, so I suggest we close this issue and re-open as a change request once an alternative is available.

@cmsdroff
Copy link
Contributor Author

In hindsight agree about blocker state at this point (as nothing we can do about it), I added that comment as for the vocab to be official output we will need to do this from what I understand in regards the process.

I think the ticket should remain open as we decided to add issue to track the conversation

Open to the project lead decision as it can be re-opened later :)

@nissimsan
Copy link
Contributor

That's fine, we can keep it around to remind ourselves to keep an ear out for updates.

@cmsdroff
Copy link
Contributor Author

Dear all made a request o note SPEC call today for a copy of the json schema that is being worked upon even in draft so we can consider what this means for us to look at change request. Will advise once received.

@cmsdroff
Copy link
Contributor Author

I think we need to push this for a draft spec adding an email reminder to api spec team

@cmsdroff
Copy link
Contributor Author

Chased and still no file provided, 'being finalised' even though we asked for a rough draft.

Without this we will continue to work on the excel export. This ticket is blocked in terms of future progression as several chasers have been sent for a json schema and we cannot be provided with an excel output that is updated. There is work in this area but not yet available.

@svanteschubert
Copy link

I do like to work on the office spreadsheet format as input format (when access is already established by the Apache POI library) as the spreadsheet is the same format the end user will likely look into by hand.

In the end, the XLS is just a container format (like XSD or upcoming JSON, etc.) which GEFEG-FX is exporting data into.
Independent if we are using XLS, JSON, etc. we are always dependent on the upstream export functionality, which might break (and is now being tested by us).

@nissimsan
Copy link
Contributor

Interesting point of view, @svanteschubert. Code-wise I would instinctively pick json over xlsx. But frankly, it works now, and I'm not thrilled about the switching cost.

From a "human browsing" experience neither of these options are good. My experience with navigating the Excel is not positive. And neither comes close to what's now possible with vocabulary.uncefact.org.

@nissimsan
Copy link
Contributor

This is stale. We've switched to the json schema output.

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

No branches or pull requests

3 participants