-
Notifications
You must be signed in to change notification settings - Fork 492
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
3648 Change "DVN" to default value "producer" and only write the firs… #7094
Conversation
…ate the external "custom download" service. Everything else is done by an outside standalone program (a java program with its own pom file). (#6505)
still working on the documentation, so will need to check it in later.
added some info to the documentation explaining how the zipper does its thing. (#6505)
(fixed merge conflicts w/develop - mostly the POST handling added for the /api/access/datafiles/ API)
Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
…tom/service/download/ZipDownloadService.java Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
…/dataverse into 6505-optimize-zip-downloads
Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
Co-authored-by: Philip Durbin <philip_durbin@harvard.edu>
@jggautier if you believe that issue should remain open, you can edit the PR description to remove the "Closes" keyword. I also added a comment references this PR to other older DDI XML issues I found in the backlog. |
Add "download all" buttons (including size of dataset) to dataset page
Public ORCID login is available.
make ec2-create-instance.sh downloadable #7099
I removed the Closes keyword and will take a look at the issues you referenced. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sending this to QA because I think there is incremental improvement in this pull request but here are a few additional thoughts:
- This pull request might be better as two smaller ones. One would remove "DVN" from "source". The other would change the behavior of the bounding box for geospatial data. (There could be separate issues for these as well.)
- It would be good to test the DDI before and after with a tool that does XML schema validation. I assume that there will be fewer failures in this pull request compared to develop. I haven't done this myself and I'm relying on what @JingMa87 has coded up and comments by @jggautier in terms of the geospatial changes being correct. It probably makes sense to someday put the XML schema validation into a test so we can continue to get it passing and keep it passing.
- This pull request changes "source" from "DVN" to "producer" but it seems like "archive" is another option. I don't feel strongly about this but some DDI experts that are part of the Dataverse community might.
@@ -328,7 +328,7 @@ private static void writeDocDescElement (XMLStreamWriter xmlw, DatasetDTO datase | |||
|
|||
private static void writeVersionStatement(XMLStreamWriter xmlw, DatasetVersionDTO datasetVersionDTO) throws XMLStreamException{ | |||
xmlw.writeStartElement("verStmt"); | |||
writeAttribute(xmlw,"source","DVN"); | |||
writeAttribute(xmlw,"source","producer"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The string "DVN_3_0" appears in if (!SOURCE_DVN_3_0.equals(xmlr.getAttributeValue(null, "source"))) {
in ImportDDIServiceBean. It's not an exact match so I don't think this will break dataset import from DDI but I thought I'd at least mention it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me it seems like the "DVN_3_0" is a legacy value and will only still be used if an old Dataverse instance hasn't upgraded yet.
@JingMa87 @jggautier before we move this to QA, do you have any thoughts about @pdurbin's comments? |
One last think to mention is that I brought up in tech hours today the idea of changing "source" from "DVN" to something more reasonable. No one objected and it sounds like it's a well known problem that "DVN" doesn't validate. |
I agree about creating a new issue for the bounding box changes. Hopefully the So this PR can be the PR for only the I would use "archive" instead of "producer," mainly because that's what's used for the "distrbtr source". But also in other places in the DDI, when source = "producer", that means the information is coming from the depositor(s) and when source = "archive", that means the information is coming from the repository. The metadata document version number is automatically generated by the repository, so maybe that's another argument for using "archive". So right now the version statement for the metadata document looks like this:
"DVN" isn't a valid value for "source". So @JingMa87 proposed changing it to producer:
Again, the distribution statement already uses "archive":
So I think the version statement should also use "archive":
What's lost in this change is the "DVN". In the current DDI export, I'm not sure what's being expressed by |
|
…t geoBndBox element with four geo coordinates.
…ix-ddi-export # Conflicts: # src/main/java/edu/harvard/iq/dataverse/export/ddi/DdiExportUtil.java # src/test/java/edu/harvard/iq/dataverse/export/ddi/dataset-finch1.xml # src/test/java/edu/harvard/iq/dataverse/export/ddi/exportfull.xml
@pdurbin How come other people's commits are in this PR? Did I use a wrong command? |
Thanks @JingMa87. About validating the XML with the codebook and pre-validation errors, when I test a codebook XML export of a dataset that has only the metadata required fields, the only other error I get (besides the "DVN" error) is about the use of |
@JingMa87 I don't know. Git is hard. 😄 I'm pretty quick to make new branches at any sign of trouble. And it looks like both @jggautier and I would prefer the "source" change to be made in a dedicated branch/pull request. |
@jggautier I actually meant that the imports that the XSD uses were faulty and prevented the validation from happening. But I fixed these in the meantime and all is well. Maybe I'll incorporate an XSD validation in the source code sometime in the future. |
…t geoBndBox element with four geo coordinates.
What this PR does / why we need it: Improves the DDI XML according to the XSD
Which issue(s) this PR closes: 3648 (doesn't close it, but it's a partial fix)
Closes nothing yet, it's an improvement
Special notes for your reviewer: It's an improvement in the DDI XML response, but more is needed in the future.
Suggestions on how to test this: Add multiple Geographic Bounding Boxes to your dataset, one with only 3 coordinates, and two with four coordinates. Only the first box with four coordinates should be in the DDI XML.
Does this PR introduce a user interface change? If mockups are available, please link/include them here: No
Is there a release notes update needed for this change?: Yes
Additional documentation: